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 20:46:16 +0100
From:	Pavel Machek <pavel@....cz>
To:	Richard Weinberger <richard@....at>
Cc:	Kees Cook <keescook@...omium.org>,
	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 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@....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?
> 
> 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-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/