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]

Message-ID: <20150103230140.GA2964@amd>
Date:	Sun, 4 Jan 2015 00:01:40 +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

On Sat 2015-01-03 23:44:18, Richard Weinberger wrote:
> Am 03.01.2015 um 23:36 schrieb Pavel Machek:
> > 
> >>>> 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).
> 
> And what about static linked programs or programs which do not use a libc wrapper
> for system calls?
> Say, any program written in go?

And what about my Atari 800XL?

How many such programs are on common distributions? <1%

How many systems will your kernel hack leave unprotected? >70%

(Plus, reasonable languages like go should not really allow classical
buffer overflows, and yes, you'll get protection if you statically
link against glibc. And AFAICT this has nothing to do with syscalls,
and everything to do with abort() implementation.).

									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/