

Big problems with ASLR in Ice Cream Sandwich - trhaynes
http://blog.duosecurity.com/2012/02/a-look-at-aslr-in-android-ice-cream-sandwich-4-0/

======
tytso
The problems which were pointed out are good ones, and they should be fixed.
Fortunately, they are easy to fix.

In the grand scheme of things, though, this isn't as bad as it seems, since
the vast majority of Android applications run in the Dalvik JVM. Hence the
amount of code that is subject to weaknesses that could be exploited by the
attacker to cause a jump into the non-randomized dynamic loader (for example)
are much smaller.

Of course, there could still be bugs in native code applications, libraries,
and system executables, so the ALSR should definitely be improved. Again,
fortunately, this should be relatively easy to do.

~~~
saurik
Yes, it should be easy to fix. That said, you downplay the weakness too
strongly: it was because of the lack of working ASLR that allowed me to use
the mempodipper exploit (as my port, "mempodroid" [1]) to get root on all the
current ICS devices. (While sometimes you can adjust an exploit to work around
ASLR, this exploit requires you to know an absolute address before the program
executes.)

[1] <https://github.com/saurik/mempodroid>

~~~
jonoberheide
Yeah, mempodroid is a great example. You'd need to randomize the location of
the setuid executable (w/PIE), randomize of the linker, and implement
something like GRKERNSEC_BRUTE to prevent trivial local bruteforcing of a
usable address.

Speaking of which, spender's recent blog post gives a good overview of some of
the grsec/PaX mitigations that would hamper the exploitation of the
/proc/pid/mem vuln:

[http://forums.grsecurity.net/viewtopic.php?f=7&t=2939](http://forums.grsecurity.net/viewtopic.php?f=7&t=2939)

~~~
saurik
Interesting... it never occurred to me that brute forcing an address was
feasible enough to bother with. ;P (edit: Although, thinking more, some
exploits have a more constrained range of addresses. That said, even here we
have a 2-3GB area, but could probably expand the target to "any instruction
executed between these points", which might be as much as a kilobyte;
requiring just a few million attempts isn't that unreasonable.)

Looking at GRKERNSEC_BRUTE, however, it would not affect this exploit: it is
designed to penalize the parent for forking exploitable children (so as, for
example, to keep new copies of Apache from coming into existence rapidly
enough for them to be remotely exploited); however, here we are assumed to
have control of the parent, so we can just add a layer of indirection, never
reusing direct parents.

~~~
jonoberheide
GRKERNSEC_BRUTE will also trigger for suid binaries (in the case of
memprodroid, run-as). See gr_handle_brute_attach() for details.

~~~
saurik
Ah, (for anyone caring enough to read this discussion) apparently the actual
code in the patch (which was more complex than listed here [1]) doesn't just
ban processes (as with control of the parent we really do have the ability to
bypass the process check, as again: we can just keep making replacement
exploit containers), but also bans entire user accounts that are causing
suspicious memory accesses.

[1] [http://xorl.wordpress.com/2010/11/09/grkernsec_brute-
exploit...](http://xorl.wordpress.com/2010/11/09/grkernsec_brute-exploit-
bruteforcing-protection/)

------
malkia
So how does the ASLR work with images optimized to be loaded at specific
address? (-fPIC all of them?)

I was under the impression that if you have two or more instances of the same
.so/.dll/.dylibs in different processes, and they end up using different
virtual addresses then they can't share the same code page. Maybe I'm behind
times...

~~~
jonoberheide
Right, all libaries need to be compiled with -fPIC in order to be randomized.
That tends to be much more common than -fPIE.

~~~
aortega
I disagree with -fPIE making things slow, specially in the ~13 general purpose
registers of ARM. Maybe -fPIE affect things in the register-starved x86, not
so much in modern archs. Also, "fucked up beyond all repair" is a little
exagerated when the repair is to add "-fPIE" to some binaries.

~~~
jonoberheide
Yeah, I'm guessing ARM will be ok with respect to GPRs (although I certainly
haven't done any benchmarks).

Dug's FUBAR comment was just an attempt cram in as many acronyms as
possible...of course the situation is improvable. ;-)

Still at CORE these days?

~~~
aortega
No more CORE for me Doc :) playing the "entrepeneur" now, without the social
app or i-phone app, so, no glamour I'm afraid.

