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, Interesting)
Game hacks are different from hacking a device where you DON'T already have root access. Typically with game hacks you are tweaking the existing behavior of an app and you have full write access to its memory to do so. With hacking a device or app you DON'T have this access, you need to get creative and exploit bugs in the app to write to memory you wouldn't normally be able to.
One example of an attack ASLR may be effective against is a stack smash. Without ASLR, if I run a program in a specific way and say, load a data file of my choosing, I may be able to assume it will get loaded into the same place in memory every time. So I can record that address, and then I can use a buffer overflow attack (perhaps using a field loaded from the same data file) to write to my stack and place the address on there. The OS then thinks my data file should be run next as code and then I can do whatever I want with the permissions of the current app.
With ASLR the location of my data file may change each run, so I can no longer hardcode an address, so now I either have to find some way to get code in a place in memory that doesn't move or find some other avenue of attack and give up on the stack smash.
(I don't do this sort of stuff so I might have gotten some details wrong but I think that's the gist of it.)
I love when people try and counter hackers (Score:5, Interesting)
Obfuscating your security is okay, but obfuscating the fact you have a bunch of anti-hacks in place seems even better.
I've been looking into anti hacker theory ever since Starcraft 1 maphackers ruined ladder.
ASLR is a good thing but... (Score:5, Interesting)
Address space layout randomisation sounds like a good idea, long overdue, and I'm glad it's slowly being rolled out.
That said - I think it's an extremely sad reflection on the state of software engineering that we simply accept that "memory corruption bugs in complex pieces of code are inevitable".
Memory corruption has such far-reaching consequences - causing the failure of pretty much every assumption of guarantee that it simply shouldn't be possible, let alone inevitable, in any industrial-strength language. We don't accept that, say, integer addition should sometimes randomly fail - although that used to happen back in the days of vacuum tubes. But we found and fixed the problem, and now our hardware is (relatively) trustworthy - yet our software is worse than ever. That we just shrug and accept memory corruption as normal - with an entire ecosystem of cybercrime and cyberwarfare created because of it - and don't seem to even think about why it might be, and how to fix the issue, but just keep slapping half-thought-out bandaid after bandaid is shameful to our profession.
(Insert image of Edsger Dijkstra surveying our burnt-out CloudPad 2.0 PHP/C++/Javascript cyberjungle with a single tear.)
Re:How stupid they think hackers are? (Score:5, Interesting)
Usually stack exploits only get a few bytes worth of executable code before everything will crash. Buffers aren't infinite in size.
If the attacker has 100 bytes worth of code that will be executed, in that space he needs to find where the rest of his code is in memory. Its difficult to find it with ASLR while staying inside your code budget.
Re:How stupid they think hackers are? (Score:5, Interesting)
This is security through obscurity; It is not going to stop the attack, it'll just mean they need to do it N times before it's more likely than not to complete.
With that definition you could also define any encryption algorithm as "security through obscurity". If N is large enough it really doesn't matter in practice.
And ASLR + data execution prevention + read only code pages makes it a LOT harder just to run any "bootstrap" code you might write to search for randomly assigned addresses in the first place - if you can't execute the heap or stack, you mostly likely need to trick the processor into jumping to some existing code that can do something more interesting for you, and if you jump to the wrong location in random memory don't expect to get another chance on that run.
It not only greatly reduces the chances of very clever malware from succeeding, it greatly reduces the pool of capable hackers who can even try...