Answers below. On Tue, Dec 13, 2011 at 1:41 AM, Dafu <[email protected]> wrote:
> 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? > Prelinking resolves library references one time, rather than having the dynamic linker perform references on every process invocation. This makes the process faster to startup. For more information about prelinking, please read: http://en.wikipedia.org/wiki/Prelink http://crast.us/james/articles/prelink.php What zygote does is different. Zygote creates an initial java virtual machine, and then forks copies of itself when spawning other java processes. In that way, java processes don't have to incur the overhead of creating a new VM themselves. This pre-forking is a valuable performance tool. > 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. > Nope. The Linux kernel does the stack randomization. See randomize_stack_top() in fs/binfmt_elf.c from the Linux kernel. No special linker tricks are done for the stack. > 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? > Address randomization occurs at exec boundaries. If you fork() without doing an exec(), you will inherit the same mappings as the process you forked from. In particular, for zygote, all zygote spawned processes have the same memory mappings *on the same device*. The mappings will be different across different devices, and across reboots of the same device. > > 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. > > -- 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.
