Hristo's ASLR work was technically very interesting and innovative. He
managed to figure out a way to make ASLR work, even in the presence of
prelinked code, by moving randomization to device re-flash / install time.
There's some tradeoffs with doing that, as Hristo points out in his paper.
One of the biggest tradeoffs is that Hristo's ASLR defenses aren't
effective against malicious local programs.

Rather than use Hristo's work, we decided to use a more traditional
approach to Android's ASLR implementation. Specifically, Android primarily
relies on the Linux kernel's ASLR implementation to provide address space
randomness.

On ARM, prior to Linux 2.6.36 / 2.6.37, the Linux kernel only supported
stack randomization. Heap, mmap, and text randomization were
*not*supported. This changed back in late 2010, with a series of
patches by
Nicolas Pitre.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=cc92c28b2d
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=990cb8acf2
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e4eab08d60

Prior to Android 4.0 (ICS), the Android system also used prelinking.
Prelinking is a valuable performance enhancement, but it also has the
effect of inhibiting ASLR. In Android 4.0, for a number of different
reasons, we decided to remove prelinking from the Android system.

Once prelinking was removed, we started walking through the Android source
code, looking at everything that was using mmap(MAP_FIXED) and changing it
to use non-fixed mappings. As you might expect, this revealed a number of
bugs, all of which were fixed during the ICS development process.

Today, the released version of Android 4.0 has stack, heap, mmap, and
shared library randomization. These ASLR features are designed to
re-enforce our already strong Linux UID application sandbox, and compliment
other memory protections already built into Android.

http://source.android.com/tech/security/index.html#memory-management-security-enhancements

Hope this helps. Please let me know if you have any further questions.

-- Nick

On Thu, Dec 1, 2011 at 7:30 AM, William Enck <[email protected]> wrote:

> Potentially based on this WiSec'11 paper?
>
> http://bojinov.org/professional/wisec2011-mobileaslr-paper.pdf
>
>
> On Dec 1, 2011, at 10:16 AM, Kevin Chadwick wrote:
>
> > On Wed, 30 Nov 2011 23:40:44 -0800 (PST)
> > Dafu wrote:
> >
> >> Is there any detail on the implementation of this feature in ICS code
> >> base? Such as in which file, which module?
> >
> > I wonder if it was based on the grsecurity arm patch or not?
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Android Security Discussions" group.
> > To post to this group, send email to
> [email protected].
> > To unsubscribe from this group, send email to
> [email protected].
> > For more options, visit this group at
> http://groups.google.com/group/android-security-discuss?hl=en.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Android Security Discussions" group.
> To post to this group, send email to
> [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/android-security-discuss?hl=en.
>
>


-- 
Nick Kralevich | Android Security | [email protected] | 650.214.4037

-- 
You received this message because you are subscribed to the Google Groups 
"Android Security Discussions" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/android-security-discuss?hl=en.

Reply via email to