From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Weinberger Subject: Re: [PATCH] [RFC] Deter exploit bruteforcing Date: Fri, 02 Jan 2015 22:40:14 +0100 Message-ID: <54A7103E.6020500@nod.at> References: <1419457167-15042-1-git-send-email-richard@nod.at> <20150102051142.GF4873@amd> <54A67A38.3000207@nod.at> <20150102194616.GA27538@amd> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: 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: <20150102194616.GA27538@amd> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Am 02.01.2015 um 20:46 schrieb Pavel Machek: >>> Does this break trinity, crashme, and similar programs? >> >> If they fork() without execve() and a child dies very fast the next fork() >> will be throttled. >> This is why I'd like to make this feature disabled by default. >> >>> Can you detect it died due to the stack canary? Then, the patch might >>> be actually acceptable. >> >> I don't think so as this is glibc specific. > > Can the slowdown be impelmented in glibc, then? glibc has a lot of asserts where it can detect stack smashing and kills the current process using abort(). Here it could of course also call sleep(). > If not, can glibc provide enough information to the kernel to allow us > to do the right thing? IMHO we should not strictly focus on the stack canary. If an attacker can kind of control the attacked child and it segfaults the generic in-kernel bruteforce detection will still work. Many exploits use the fact that after fork() the child has the same memory as before and brute force is possible. A user space solution won't help here. Thanks, //richard