Big problems with ASLR in Ice Cream Sandwich
blog.duosecurity.com
Big problems with ASLR in Ice Cream Sandwich
1–10 of 19 posts
Re: Big problems with ASLR in Ice Cream Sandwich
#2The 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.
Re: Big problems with ASLR in Ice Cream Sandwich
#3The 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…
There's still a large attack surface of native code in the Android platform. I've heard WebKit has a few bugs... :-P
Re: Big problems with ASLR in Ice Cream Sandwich
#4The 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…
There's still a large attack surface of native code in the Android platform. I've heard WebKit has a few bugs... :-P
This is why I think Chrome for Android is a big deal. The browser will always be one of the easiest ways run an exploit. With the browser tightly coupled with the OS, many old phones will never receive an update for it.
The WebView as attack target is a different story, though.
Re: Big problems with ASLR in Ice Cream Sandwich
#5So 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...
Re: Big problems with ASLR in Ice Cream Sandwich
#6The 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…
There's still a large attack surface of native code in the Android platform. I've heard WebKit has a few bugs... :-P
You made a great point. Why did you have to ruin it with an emoticon?
Re: Big problems with ASLR in Ice Cream Sandwich
#7So 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...
Right, all libaries need to be compiled with -fPIC in order to be randomized. That tends to be much more common than -fPIE.
Re: Big problems with ASLR in Ice Cream Sandwich
#8Earlier quoted context omitted.
There's still a large attack surface of native code in the Android platform. I've heard WebKit has a few bugs... :-P
You made a great point. Why did you have to ruin it with an emoticon?
Because they're common speech patterns on the internet these days, where it's difficult to show emotion via text. You could have just as easily said "why did you grin after saying you ate pizza?". A better question might have been: "Why the 'sticks tongue out at in silly manner' face?"
Re: Big problems with ASLR in Ice Cream Sandwich
#9The 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…
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.)
Re: Big problems with ASLR in Ice Cream Sandwich
#10The 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…
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/sa…
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: