Message-ID: <87r3k5mn4s.fsf@x220.int.ebiederm.org>
Date:	Wed, 04 Nov 2015 16:10:43 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Daniel Cashman <dcashman@...roid.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux@....linux.org.uk,
	keescook@...omium.org, mingo@...nel.org,
	linux-arm-kernel@...ts.infradead.org, corbet@....net,
	dzickus@...hat.com, xypron.glpk@....de, jpoimboe@...hat.com,
	kirill.shutemov@...ux.intel.com, n-horiguchi@...jp.nec.com,
	aarcange@...hat.com, mgorman@...e.de, tglx@...utronix.de,
	rientjes@...gle.com, linux-mm@...ck.org, linux-doc@...r.kernel.org,
	salyzyn@...roid.com, jeffv@...gle.com, nnk@...gle.com,
	dcashman <dcashman@...gle.com>
Subject: Re: [PATCH v2 1/2] mm: mmap: Add new /proc tunable for mmap_base ASLR.

Daniel Cashman <dcashman@...roid.com> writes:

> On 11/3/15 5:31 PM, Andrew Morton wrote:
>> On Tue, 03 Nov 2015 18:40:31 -0600 ebiederm@...ssion.com (Eric W. Biederman) wrote:
>> 
>>> Andrew Morton <akpm@...ux-foundation.org> writes:
>>>
>>>> On Tue,  3 Nov 2015 10:10:03 -0800 Daniel Cashman <dcashman@...roid.com> wrote:
>>>>
>>>>> ASLR currently only uses 8 bits to generate the random offset for the
>>>>> mmap base address on 32 bit architectures. This value was chosen to
>>>>> prevent a poorly chosen value from dividing the address space in such
>>>>> a way as to prevent large allocations. This may not be an issue on all
>>>>> platforms. Allow the specification of a minimum number of bits so that
>>>>> platforms desiring greater ASLR protection may determine where to place
>>>>> the trade-off.
>>>>
>>>> Can we please include a very good description of the motivation for this
>>>> change?  What is inadequate about the current code, what value does the
>>>> enhancement have to our users, what real-world problems are being solved,
>>>> etc.
>>>>
>>>> Because all we have at present is "greater ASLR protection", which doesn't
>>>> really tell anyone anything.
>>>
>>> The description seemed clear to me.
>>>
>>> More random bits, more entropy, more work needed to brute force.
>>>
>>> 8 bits only requires 256 tries (or a 1 in 256) chance to brute force
>>> something.
>> 
>> Of course, but that's not really very useful.
>> 
>>> We have seen in the last couple of months on Android how only having 8 bits
>>> doesn't help much.
>> 
>> Now THAT is important.  What happened here and how well does the
>> proposed fix improve things?  How much longer will a brute-force attack
>> take to succeed, with a particular set of kernel parameters?  Is the
>> new duration considered to be sufficiently long and if not, are there
>> alternative fixes we should be looking at?
>> 
>> Stuff like this.
>> 
>>> Each additional bit doubles the protection (and unfortunately also
>>> increases fragmentation of the userspace address space).
>> 
>> OK, so the benefit comes with a cost and people who are configuring
>> systems (and the people who are reviewing this patchset!) need to
>> understand the tradeoffs.  Please.
>
> The direct motivation here was in response to the libstagefright
> vulnerabilities that affected Android, specifically to information
> provided by Google's project zero at:
>
> http://googleprojectzero.blogspot.com/2015/09/stagefrightened.html
>
> The attack there specifically used the limited randomness used in
> generating the mmap base address as part of a brute-force-based exploit.
>  In this particular case, the attack was against the mediaserver process
> on Android, which was limited to respawning every 5 seconds, giving the
> attacker an average expected success rate of defeating the mmap ASLR
> after over 10 minutes (128 tries at 5 seconds each).  With change to the
> maximum proposed value of 16 bits, this would change to over 45 hours
> (32768 tries), which would make the user of such a system much more
> likely to notice such an attack.
>
> I understand the desire for this clarification, and will happily try to
> improve the explanation for this change, especially so that those
> considering use of this option understand the tradeoffs, but I also view
> this as one particular hardening change which is a component of making
> attacks such as these harder, rather than the only solution.  As for the
> clarification itself, where would you like it?  I could include a cover
> letter for this patch-set, elaborate more in the commit message itself,
> add more to the Kconfig help description, or some combination of the above.

Unless I am mistaken this there is no cross over between different
processes of this randomization.  Would it make sense to have this as
an rlimit so that if you have processes on the system that are affected
by the tradeoff differently this setting can be changed per process?

Eric
--
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