From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Weinberger Subject: Re: [PATCH] [RFC] Deter exploit bruteforcing Date: Sun, 04 Jan 2015 00:07:18 +0100 Message-ID: <54A87626.4070302@nod.at> References: <20150102222936.GA29018@amd> <20150102224646.GB29018@amd> <20150102225420.GC29018@amd> <54A72306.2050908@nod.at> <20150102230837.GA4482@amd> <54A7BA45.1050005@nod.at> <20150103223644.GB27979@amd> <54A870C2.9080102@nod.at> <20150103230140.GA2964@amd> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Jiri Kosina , Kees Cook , LKML , "linux-fsdevel@vger.kernel.org" , David Rientjes , Aaron Tomlin , DaeSeok Youn , Thomas Gleixner , vdavydov@parallels.com, Rik van Riel , Oleg Nesterov , Andrew Morton , Peter Zijlstra , Ingo Molnar , Al Viro , Andy Lutomirski , Brad Spengler To: Pavel Machek Return-path: Received: from a.ns.miles-group.at ([95.130.255.143]:65275 "EHLO radon.swed.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752495AbbACXHW (ORCPT ); Sat, 3 Jan 2015 18:07:22 -0500 In-Reply-To: <20150103230140.GA2964@amd> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Am 04.01.2015 um 00:01 schrieb Pavel Machek: > On Sat 2015-01-03 23:44:18, Richard Weinberger wrote: >> Am 03.01.2015 um 23:36 schrieb Pavel Machek: >>> >>>>>> No. This is not what this patch does. >>>>>> >>>>>>> But changing glibc to do sleep(30); abort(); instead of abort(); to >>>>>>> slow down bruteforcing of canaries makes some kind of sense... and >>>>>>> should be ok by default. >>>>>> >>>>>> As I saidn only focusing one the specific stack canary case is not enough. >>>>> >>>>> Ok, so I am now saying "adding random delays to the kernel, hoping >>>>> they slow attacker down" is bad idea. Feel free to add my NAK to the >>>>> patch. >>>> >>>> The patch does not add random delays nor is hope involved. >>>> >>>> It has a very clear purpose, it makes brute force attacks to forking >>>> services unattractive. >>>> Exploits often use the fact that after fork() the child has the same memory >>>> as the parent and therefore an attacker can start fruitful brute force attacks >>>> to brute stack canaries, offsets, etc. as the new child will always have mostly >>>> the same memory layout as before. >>>> >>>> But I'll happily add your NAK to this series. >>> >>> Please do. >>> >>>>> If really neccessary, "kill_me_slowly()" syscall would be acceptable, >>>>> but it seems just sleep(); abort(); combination is enough. >>>> >>>> The goal of the patch is not to protect only against brute forcing the stack canary. >>>> It should protect against all kind of brute forcing using forking services. >>>> >>>>> glibc should cover 99% cases where this matters, please just fix glibc, >>>>> others will follow. >>>> >>>> There are a lot of systems out there without glibc. >>> >>> Only "interesting" systems that are without glibc are androids, and >>> they usually run very old kernels. >>> >>> If you implement sleep() in glibc, distros will enable it and you'll >>> protect all the desktop users. >>> >>> If you implement it in kernel, it will not be compatible-enough to be >>> enabled by default, and you'll be protecting special "high security" >>> distros at most. >>> >>>> And many applications make system calls without going though any libc wrapper. >>>> Hey, we want also protect esoteric distros like http://sta.li. :-) >>> >>> No, we don't. We want to maximize number of protected users. And >>> patching glibc does that. (And then you can patch bionic. And then the >>> small players will follow). >> >> And what about static linked programs or programs which do not use a libc wrapper >> for system calls? >> Say, any program written in go? > > And what about my Atari 800XL? If it runs Linux it can be protected. > How many such programs are on common distributions? <1% > > How many systems will your kernel hack leave unprotected? >70% > > (Plus, reasonable languages like go should not really allow classical > buffer overflows, and yes, you'll get protection if you statically > link against glibc. And AFAICT this has nothing to do with syscalls, > and everything to do with abort() implementation.). Go does not use libc at all. Anyway, you've stated your point. I'm for a generic solution and not for one which works only for some systems. Thanks, //richard