Android Jelly Bean Much Harder To Hack 184
A reader 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."
Re:How stupid they think hackers are? (Score:5, Informative)
Re:How stupid they think hackers are? (Score:5, Informative)
> 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.
Re:How stupid they think hackers are? (Score:5, Informative)
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.
Re:How stupid they think hackers are? (Score:0, Informative)
I think you're confusing ASLR with NX / W^X.
W^X came out first, at least in popular OSs. In fact, ASLR is even worse with W^X on x86-32, because X86-32 does W^X using a simple address space segmentation, halving the space available for ASLR.
ASLR isn't useless on x86-32, just not as effective as some people think. Because of W^X, you've halved your address space.
You lose a bunch with kernel/user space segmentation. Libraries usually have to be loaded at page boundaries, so divide by, say, 4096. The number of possible locations is actually quite small in the grand scheme of things. For a massive distributed attack you're definitely going to randomly succeed a significant number of attempts, especially if you get more than one shot at any one target.
You forget that unlike Windows, OpenBSD and Linux were 64-bit capable for like a decade. ASLR made sense because those OSs already ran on 64-bit hardware.
Re:How does this compare to the competition? (Score:0, Informative)
It's been in Android since 4.0 (Ice Cream Sandwich), which was released in mid-2011.
"Gasp! Does this mean a Slashdot summary might be incorrect?! Perish the fucking thought!"
Re:Simple Minded Question (Score:4, Informative)
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.
Re:unix permissions? (Score:4, Informative)
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/ [androidpolice.com]
Re:How stupid they think hackers are? (Score:5, Informative)
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.
Re:How stupid they think hackers are? (Score:3, Informative)
The APIs are loaded in the procedure linkage table, referenced at an offset. Basically a PLT call is done by jumping to %epc+OFFSET, where OFFSET is the distance between the current position in the library and the position of the entry in the PLT to make a particular call. At that position a call is actually made, though it may be unresolved; if it's the first time that function has been called, the PLT executes a small piece of code to link that function, resolving and caching its load address. Then or otherwise, it makes the actual call.
Information is stored in the Global Offset Table (data) and the PLT in each library. This includes information about where in memory other shit is. If you randomize the bases, a piece of code still knows it's 379264 bytes to its PLT from a particular instruction; of course that's somewhere random in memory, but no matter since we know where we are now.
On 32-bit systems, ASLR can make success rates 1 in 65k, or .0015%, because library calls have to be precise and more than 256MB of randomness is unreasonable. The stack can move aligned to 16 bytes, but you can nullify that with a NOP slide--a non-executable stack makes the stack pure data, and thus can supply a good 1 in a million shot if you need to use it to store something (like a new executable file to write out to disk?).
When you have a 1 in 65k chance of success, you cause on average 32 THOUSAND failures to get ONE success out of a fork()ing program that keeps the same address space for each request. If the process re-initializes between attacks, you'll average 65 THOUSAND attacks per 1 success. It's easy to spot that kind of assault; some security tools even recognize repeated crashing and slow the processes down or send alerts. If we look at the connections to a process that crashes, we can surmise the common one(s) are the attackers if there's a single staging point. At the least you lose stealth.