From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Weinberger Subject: Re: [PATCH] [RFC] Deter exploit bruteforcing Date: Sat, 03 Jan 2015 23:44:18 +0100 Message-ID: <54A870C2.9080102@nod.at> References: <20150102194616.GA27538@amd> <54A7103E.6020500@nod.at> <20150102222936.GA29018@amd> <20150102224646.GB29018@amd> <20150102225420.GC29018@amd> <54A72306.2050908@nod.at> <20150102230837.GA4482@amd> <54A7BA45.1050005@nod.at> <20150103223644.GB27979@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: In-Reply-To: <20150103223644.GB27979@amd> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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? Thanks, //richard