Slashdot Mirror
Android Jelly Bean Much Harder To Hack
New submitter SternisheFan tips this quote from an article at Ars:
"The latest release of Google's Android mobile operating system has finally been properly fortified with an industry-standard defense. It's designed to protect end users against hack attacks that install malware on handsets. In an analysis published Monday, security researcher Jon Oberheide said Android version 4.1, aka Jelly Bean, is the first version of the Google-developed OS to properly implement a protection known as address space layout randomization. ASLR, as it's more often referred to, randomizes the memory locations for the library, stack, heap, and most other OS data structures. As a result, hackers who exploit memory corruption bugs that inevitably crop up in complex pieces of code are unable to know in advance where their malicious payloads will be loaded. When combined with a separate defense known as data execution prevention, ASLR can effectively neutralize such attacks."
One more thing: the fallacy you've accidentally found yourself in, where you're comparing hacking while already having root access to hacking a device where you have minimal access (with the goal of getting root access) is rather common.
> Windows - or it's compilers - have always had data and code location randomization
False. ASLR was added in Windows Vista
> One popular method of establishing this is to rely on fingerprints.
Unapplicable to ASLR.
> Google is adding something that other OSes have had for decades and making a huge noise about it
False. a) Most OSes got it in late 2000's, b) ASLR is in Android since ICS and it's just a tick in feature list, not "huge noise"
Fresh account, single post, praising Windows and bashing Google in the same minute as article with a huge lacking in facts department. Yup, it's another sockpuppet troll. Hope the idiots modding you up get their due from metamods.
Bullet-proof vests are security through obscurity! They're not going to stop the attack, it just means etc.
The point of ASLR is that shitty code that got pwned by buffer overflow 100 times out of 100 now will be pwned one time out of (pow(8, sizeof(void*))/RANDOMIZATION_STEP).
If randomization can place it at any 4k page in 32 bit space, you get 1/1048576 probability malicious code works. With 16 bit steps for ASLR, you get 1/65536. Sure can be bruteforced, but that's not very applicable to client applications, especially considering the app will most likely crash every time you guess wrong.
Harvard architecture parts are still around but largely confined to microcontrollers and the simpler DSPs at this point. The separation doesn't fix the software problem of buffer over/underruns. It just means you can't easily spill over into a code segment and do nasty things as a byproduct of that. You can still do dirty things in the data segment, though.
I am becoming gerund, destroyer of verbs.
Then you want a phone with CyanogenMod It's got pretty fine grained control for denying apps certain permissions. Take a look:
http://www.androidpolice.com/2011/05/22/cyanogenmod-adds-support-for-revoking-and-faking-app-permissions/
-------
Drink Coffee - Do Stupid Things Faster And With More Energy!
It's not "security through obscurity" any more than, say, encryption is. With encryption, you can also get the right answer by guessing enough times.
Memory layout randomisation is actually worse for the attacker, because every failed attempt at running the malicious code will cause the app to crash, so someone will notice something is wrong (or simply uninstall the app) long before it succeeds.