Hi Nick,
I have several further questions on this topic:
1. From your comments, in ICS, prelink is removed.
I checked the process "zygote" in ICS. It still links to lots of
shared libraries, which is the same as Android previous versions. So
what is your meaning of removing prelink?
2. Random addressing of stack.
In my experience, the starting address of the stack is defined in
linking period of a linker (saying arm-xxx-ld). For randomness of
stack, you mean Android adds randomness tricks in app/lib's linking
script? Please feel free to correct me if I am wrong.
3. Random addressing of shared library.
Let me give an example for this question. If process B is forked from
process A, which is linked to a shared library C. The address of lib C
in process B still keeps the same as what it looks at process A? If
yes, what is your meaning of shared library randomness?
Thanks,
Dafu
On 12月6日, 下午10时45分, Nick Kralevich <[email protected]> wrote:
> Code to randomize the location of the linker itself has been checked in and
> will be available in a future Android release. (this was trickier than you
> might imagine)
>
> -- Nick
>
> On Tue, Dec 6, 2011 at 4:19 AM, Rodrigo Chiossi
> <[email protected]>wrote:
>
>
>
>
>
>
>
>
>
> > Any progress on the Dynamic Linker itself? It still seems to be position
> > dependent..
>
> > On Sat, Dec 3, 2011 at 3:03 PM, Nick Kralevich <[email protected]> wrote:
>
> >> 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=co...
>
> >>http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=co...
>
> >>http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=co...
>
> >> 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-...
>
> >> 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.
>
> --
> 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.
