Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Kees Cook <keescook <at> chromium.org>
Subject: Re: [PATCH 3/3] x86: kernel base offset ASLR
Newsgroups: gmane.linux.kernel.hardened.devel
Date: Thursday 4th April 2013 20:54:36 UTC (over 4 years ago)
On Thu, Apr 4, 2013 at 1:12 PM, H. Peter Anvin  wrote:
> On 04/04/2013 01:07 PM, Kees Cook wrote:
>> However, the benefits of
>> this feature in certain environments exceed the perceived weaknesses[2].
>
> Could you clarify?

I would summarize the discussion of KASLR weaknesses into to two
general observations:
1- it depends on address location secrecy and leaks are common/easy.
2- it has low entropy so attack success rates may be high.

For "1", as Julien mentions, remote attacks and attacks from a
significantly contained process (via seccomp-bpf) minimizes the leak
exposure. For local attacks, cache timing attacks and other things
also exist, but the ASLR can be improved to defend against that too.
So, KASLR is useful on systems that are virtualization hosts,
providing remote services, or running locally confined processes.

For "2", I think that the comparison to userspace ASLR entropy isn't
as direct. For userspace, most systems don't tend to have any kind of
watchdog on segfaulting processes, so a remote attacker could just
keep trying an attack until they got lucky, in which case low entropy
is a serious problem. In the case of KASLR, a single attack failure
means the system goes down, which makes mounting an attack much more
difficult. I think 8 bits is fine to start with, and I think start
with a base offset ASLR is a good first step. We can improve things in
the future.

-Kees

--
Kees Cook
Chrome OS Security
 
CD: 3ms