On Fri 2015-01-02 12:00:08, Richard Weinberger wrote: > Am 02.01.2015 um 06:11 schrieb Pavel Machek: > > On Tue 2014-12-30 10:40:15, Kees Cook wrote: > >> On Wed, Dec 24, 2014 at 1:39 PM, Richard Weinberger <richard@xxxxxx> wrote: > >>> While exploring the offset2lib attack I remembered that > >>> grsecurity has an interesting feature to make such attacks > >>> much harder. Exploits can brute stack canaries often very easily > >>> if the target is a forking server like sshd or Apache httpd. > >>> The problem is that after fork() the child has by definition > >>> exactly the same memory as the parent and therefore also the same > >>> stack canaries. > >>> The attacker can guess the stack canaries byte by byte. > >>> After 256 times 7 forks() a good exploit can find the correct > >>> canary value. > >>> > >>> The basic idea behind this patch is to delay fork() if a child died > >>> due to a fatal error. > >>> Currently it delays fork() by 30 seconds if the parent tries to fork() > >>> within 60 seconds after a child died due to a fatal error. > >>> > >>> I'm sure you'll hate this patch but I want to find out how much you hate it > >>> and whether there is a little chance to get it mainline in a modified form. > >>> Later I'd make it depend on a new Kconfig option and off by default > >>> and the timing constants changeable via sysctl. > > > > 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? If not, can glibc provide enough information to the kernel to allow us to do the right thing? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
