Date:	Mon, 5 Jan 2015 14:56:51 -0800
From:	Kees Cook <keescook@...omium.org>
To:	Richard Weinberger <richard@....at>
Cc:	Andy Lutomirski <luto@...capital.net>, Pavel Machek <pavel@....cz>,
	Jiri Kosina <jkosina@...e.cz>,
	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>,
	Brad Spengler <spender@...ecurity.net>,
	PaX Team <pageexec@...email.hu>
Subject: Re: [PATCH] [RFC] Deter exploit bruteforcing

On Sat, Jan 3, 2015 at 3:19 PM, Richard Weinberger <richard@....at> wrote:
> Am 04.01.2015 um 00:06 schrieb Andy Lutomirski:
>> As an attempt to help end this particular line of debate: putting the
>> sleep in glibc won't work.  The point isn't to make the crashed
>> process crash more slowly; it's to limit the rate at which *new*
>> siblings can be forked and crashed as a canary or ASLR brute-force
>> probe.  IOW, adding a sleep call to glibc slows down the wrong thing.
>> Also, trying to get libc to take action on a plain old segfault is a
>> giant mess, because it involves mucking with signal handling, which
>> glibc really has no business doing by default.
>
> Thanks for pointing this out!

Yeah, this doesn't belong in glibc. The support for fork-speed-control
must be in the kernel. Improving glibc is an entirely separate idea.

For glibc, it would be nice to create a "halp, I'm being attacked"
syscall that like abort(), but used in cases of memory corruption,
etc. This would provide a much cleaner way for programs to communicate
to the kernel that something malicious is happening. Neither SIGABRT
nor SIGSYS are quite right for this, but SIGSYS (as used by seccomp)
is likely closer.

>> Also, this patch is missing a bit, I think.  We really want to control
>> the total rate of crashes.  This patch imposes a delay per crash, but
>> AFAICS it would still be possible for an attacker to coerce a forking
>> server to fork, say, 10k children, then probe all of them, then wait
>> 30 seconds and repeat.

I general, while I would expect this to be limited by the default
RLIMIT_NOFILE of 1024, it's still a valid observation, though the
scope is smaller. Regardless, it would still be a defensive benefit to
slow down forks.

Brad, PaXTeam: have you considered limiting open connections from the
same IP address or anything like that for defending against this kind
"wide prefork" attack?

> Sounds reasonable. This is exactly why I've extracted that feature from
> grsecurity and posted it here on LKML.
> Now we have the chance to make the feature better and can identify weak points.

The grsecurity version also handles set[ug]id binaries more aggressively.
https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Deter_exploit_bruteforcing

Speaking to "default or not", it needs to be off by default in the
kernel configs. It's easy to imagine things that will trip on false
positives, so we must first get the system in place in the kernel and
improve it until we get to the point where we can set it on by default
(this may take years, after all the distros are using it, etc etc).
Security feature addition requires a fair bit of patience. :)

If you can spin up a version with sysctls and Kconfig stuff, I think
that'd be the best next step.

-Kees

-- 
Kees Cook
Chrome OS Security
--
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/

Powered by blists - more mailing lists