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 for Android: free password hash cracker in your pocket

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

Message-ID: <20150103223644.GB27979@amd>
Date:	Sat, 3 Jan 2015 23:36:44 +0100
From:	Pavel Machek <pavel@....cz>
To:	Richard Weinberger <richard@....at>
Cc:	Jiri Kosina <jkosina@...e.cz>, 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


> >> 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).

									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/