linux-kernel - Re: [PATCH 3/3] x86: kernel base offset ASLR

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]

Date:	Thu, 4 Apr 2013 14:01:39 -0700
From:	Eric Northup <digitaleric@...gle.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Kees Cook <keescook@...omium.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"kernel-hardening@...ts.openwall.com" 
	<kernel-hardening@...ts.openwall.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"x86@...nel.org" <x86@...nel.org>,
	Jarkko Sakkinen <jarkko.sakkinen@...el.com>,
	Matthew Garrett <mjg@...hat.com>,
	Matt Fleming <matt.fleming@...el.com>,
	Dan Rosenberg <drosenberg@...curity.com>,
	Julien Tinnes <jln@...gle.com>, Will Drewry <wad@...omium.org>
Subject: Re: [PATCH 3/3] x86: kernel base offset ASLR

On Thu, Apr 4, 2013 at 1:58 PM, H. Peter Anvin <hpa@...or.com> wrote:
> It seems to me that you are assuming that the attacker is targeting a specific system, but a bot might as well target 256 different systems and see what sticks...

The alarm signal from the ones that don't stick is, in my opinion, the
primary benefit from this work -- it makes certain classes of attack
much less economical.  A crash dump from a panic'd machine may include
enough information to diagnose the exploited vulnerability - and once
diagnosed and fixed, knowledge about the vulnerability is much less
valuable.

>
> Kees Cook <keescook@...omium.org> 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[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
>
> --
> Sent from my mobile phone. Please excuse brevity and lack of formatting.
--
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/