Date: Fri, 5 Apr 2013 09:05:30 +0200 From: Ingo Molnar <mingo@...nel.org> To: Julien Tinnes <jln@...gle.com> Cc: "H. Peter Anvin" <hpa@...or.com>, Kees Cook <keescook@...omium.org>, linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, x86@...nel.org, Jarkko Sakkinen <jarkko.sakkinen@...el.com>, Matthew Garrett <mjg@...hat.com>, Matt Fleming <matt.fleming@...el.com>, Eric Northup <digitaleric@...gle.com>, Dan Rosenberg <drosenberg@...curity.com>, Will Drewry <wad@...omium.org>, Linus Torvalds <torvalds@...ux-foundation.org> Subject: Re: [PATCH 3/3] x86: kernel base offset ASLR * Julien Tinnes <jln@...gle.com> wrote: > On Thu, Apr 4, 2013 at 1:27 PM, H. Peter Anvin <hpa@...or.com> wrote: > > On 04/04/2013 01:23 PM, Julien Tinnes wrote: > >> On Thu, Apr 4, 2013 at 1:19 PM, Julien Tinnes <jln@...gle.com> wrote: > >>> On Thu, Apr 4, 2013 at 1:12 PM, H. Peter Anvin <hpa@...or.com> wrote: > >>>> On 04/04/2013 01:07 PM, Kees Cook wrote: > >>>>> However, the benefits of > >>>>> this feature in certain environments exceed the perceived weaknesses. > >>>> > >>>> Could you clarify? > >>> > >>> I think privilege reduction in general, and sandboxing in particular, > >>> can make KASLR even more useful. A lot of the information leaks can be > >>> mitigated in the same way as attack surface and vulnerabilities can be > >>> mitigated. > >> > >> Case in point: > >> - leaks of 64 bits kernel values to userland in compatibility > >> sub-mode. Sandboxing by using seccomp-bpf can restrict a process to > >> the 64-bit mode API. > >> - restricting access to the syslog() system call > >> > > > > That doesn't really speak to the value proposition. My concern is that > > we're going to spend a lot of time chasing/plugging infoleaks instead of > > tackling bigger problems. > > Certain leaks are already an issue, even without kernel base > randomization. Definitely. Stealth infiltration needs a high reliability expoit, especially if the attack vector used is a zero day kernel vulnerability. Injecting uncertainty gives us a chance to get a crash logged and the vulnerability exposed. > But yeah, this would give an incentive to plug more infoleaks. I'm not > sure what cost this would incur on kernel development. I consider it a plus on kernel development - the more incentives to plug infoleaks, the better. > There are by-design ones (printk) and bugs. I think we would want to > correct bugs regardless? Definitely. > For by-design ones, privilege-reduction can often be an appropriate answer. Correct, that's the motivation behind kptr_restrict and dmsg_restrict. > I really see KASLR as the next natural step: > > 1. Enforce different privilege levels via the kernel > 2. Attackers attack the kernel directly > 3a. Allow user-land to restrict the kernel's attack surface and > develop sandboxes (seccomp-bpf, kvm..) > 3b. Add more exploitation defenses to the kernel, leveraging (3a) and (1). > > > 8 bits of entropy is not a lot. > > It would certainly be nice to have more, but it's a good first start. > Unlike user-land segfaults, many kernel-mode panics aren't recoverable > for an attacker. The other aspect of even just a couple of bits of extra entropy is that it changes the economics of worms and other remote attacks: there's a significant difference between being able to infect one machine per packet and only 1 out of 256 machines while the other 255 get crashed. The downside is debuggability - so things like 'debug' on the kernel boot command line should probably disable this feature automatically. Thanks, Ingo
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.