linux-kernel - Re: [PATCH] [RFC] Deter exploit bruteforcing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 2 Jan 2015 06:11:42 +0100
From:	Pavel Machek <pavel@....cz>
To:	Kees Cook <keescook@...omium.org>
Cc:	Richard Weinberger <richard@....at>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	David Rientjes <rientjes@...gle.com>,
	Aaron Tomlin <atomlin@...hat.com>,
	DaeSeok Youn <daeseok.youn@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>, vdavydov@...allels.com,
	Rik van Riel <riel@...hat.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Andy Lutomirski <luto@...capital.net>,
	Brad Spengler <spender@...ecurity.net>
Subject: Re: [PATCH] [RFC] Deter exploit bruteforcing

On Tue 2014-12-30 10:40:15, Kees Cook wrote:
> On Wed, Dec 24, 2014 at 1:39 PM, Richard Weinberger <richard@....at> 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?

Can you detect it died due to the stack canary? Then, the patch might
be actually acceptable.

								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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/