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."
Android Jelly Bean Much Harder To Hack
I can't wait to show this headline to my non-computer-type friends and watch their heads explode.
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.)
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.
From my experience with hackers, if you say your platform is more challenging to hack, it attracts more hackers to try and hack it. Never taunt happy fun hackers.
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.
God spoke to me
Will be hackable with a sonic screwdriver.
What? Exploiting a flaw in a vulnerable web browser on a mobile device has little to do with standard Unix/Linux permissions. The malware inserted into the browser will run with the privileges of the browser, which is more than enough to cause a lot of grief. Even if the browser is sand boxed, the malware can steal any data put into the browser such as credit card #s or email/banking logins. It's very useful to make this as hard as possible.
"...I think the Microsoft hatred is a disease." - Linus Torvalds
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.)
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
I really wish I hadn't run off the edge of my trackpad and accidentally modded GP "redundant", forcing me to post this and undo all my mods in the thread.
AGAIN.
> 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.
not really it has a unlocked boot loader which is great but i still don't have sudo privileges and i don't have fine grained permission on a user group read write execute level. not to mention SELinux security which would be great. ideally i would be able to give each app its own permissions to every resource. dose this app get contacts read permission? i say nope it doesn't even know there is a contacts list. does it see my 3g Internet and use it to serve me ads and cost me minutes or toward my date cap? nope wifi only for it. or no Internet privileges for any that don't need it. does this app get to see all of my photo's nope only the ones in this folder.
do most people need this probably not (but then again they really do need this but they wouldn't know how to take advantage of it and would brick their phone by taking away their own screen privileges) so just set it up like ubuntu does for permissions you hide it all behind a few menus maybe a sudo command and let me have complete control of my devise.
---Saying gnome 3 is better than windows 8 not so much a compliment as it is damning with light praise.
A quick look at Oberheide's site shows a talk from a week ago at Summer Con detailing problems with Google's 'Bouncer' system, designed to detect malicious apps before they enter the Android Market:
http://jon.oberheide.org/blog/2012/06/21/dissecting-the-android-bouncer/
http://jon.oberheide.org/files/summercon12-bouncer.pdf
The executive summary:
Bouncer doesn't have to be perfect to
be useful
â-- It will catch crappy malware
â-- It won't catch sophisticated malware
â-- Same as AV, IDS,
â-- How much does Bouncer raise the
bar?
â-- Currently: not much
â-- Future: hopefully more?
The English word fart is one of the oldest words in the English vocabulary.
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.
It is a PHONE. Not a fucking workstation.
yes it is a phone but why take out functionality that is already built in.
Every process on Android is run under a different user respecting the permission system built into the Linux kernel.
yes and they have every permission they want not the permissions i want them to have.
Trying to turn your phone into a desktop is pointless.
its not pointless. i want a secure device. and apps that can't steal my data.
Just use the desktop when you need to go that far with it
do you have a desktop you can fit in you pants pocket with a capacitive touch screen, 3g blue tooth and wifi connections, a battery life measured in days and telephony stack?
And if you really want to use your phone, install Linux in a chroot and go to town with sudo.
android already has linux on it its just broken
---Saying gnome 3 is better than windows 8 not so much a compliment as it is damning with light praise.
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.
I'm reading through this thread, and the standard response made by anyone who disagrees with a post is to either call them a moron, idiot, motherfucker, or to insinuate they are gay.
How about this? If you guys think that a post is inaccurate or simplistic - consider responding and explaining why the post is wrong. If you can't do that, then maybe your level of understanding on this topic is lower than you think it is.
I mean, come on. I realize this is Slashdot, and there are always a few people like that hanging around - but this story seems to be attracting an inordinate number of guys that have nothing to offer but anger and venom.
#DeleteChrome
What ever happened to processors designed to keep data and code execution spaces separate? It was done in the 1980s on processors with far far fewer gates. While it made application design a bit more 'thoughtful', I don't remember any designers complaining about it. Maybe I'm old fashioned, but aren't buffer/stack overruns/underruns a hardware architectural issue? If so, then why don't they fix the hardware?
I'm risking getting a little trollish myself, but I was just joking about this particular issue in an earlier story.
Aside from the reference models, very slow roll-outs and platform fragmentation in the Android ecosystem is, I think, a real and irritating problem. I think that's fair for us to talk about it, if only because I'd like to see manufacturers and carriers do a better job.
On the other hand, the first iPhone came out in the U.S. on June 29, 2007 and the first Android phone on October 22, 2008, so Google introduced the tech into its line of phones at about the same delta-relative-to-initial-release as Apple. As you note, Apple had a head start.
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...
And if the stack is read-only you basically get 1 instruction, the address for a return/jump/etc. And every time you fail you (most likely) crash.
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!
I'm sure you're right. If enough customers cared, the carriers and manufacturers would care.
And I'm nobody important so my opinion isn't really worth anything, but as both an amateur developer and even just as a user I get a little cranky about all the new (and new-ish) phones not getting new software.
I'd like to have things like Google Now, the offline voice stuff, etc. I can get a lot of that stuff on my phone in one way or another, but you can't help but think to yourself, "Apple users don't have this problem". It has something of a second-class stigma about it. That stings a little when your phone cost you more than an iPhone.
Of course the catch there is that not all Apple devices get all the new features when they get updated. And you can root most Android devices and install CM if you want the good stuff. Or if you have no other constraints (business or otherwise) you can buy the reference model and it's not really an issue.
But let's be honest... Apple's total control, for whatever problems it comes with, does do the update thing better.
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.
How did this get modded troll? Someone on google's android team must have a slashdot account...
It was so off the mark, the moderator must have thought it was a joke.
Memory layout randomisation means intentionally loading code at random locations, to make it as hard as possible for the hacker. The GP is confusing this with not having fixed locations for code, which means it *may* be loaded at different locations (but usually is loaded to a location close to the previous one). The latter has been around for decades, but the former has only become common during the last decade.
It's like the difference between having 365 different castles to sleep in (but not caring which one you choose), which makes it slighty harder for an assassin to get at you, and intentionally choosing a castle at random every night, which makes it much harder for the assassin.
Finding memory locations with fingerprints doesn't get you far in itself, since you need to find the location of code in memory space that belongs to *root* or *other users*, and that memory is read/write-protected.
The OP is trying to apply his (admittedly valid) knowledge about hacking gaming systems or old versions of Windows to modern operating systems.
What they really need to do is to include fake data. Some apps just crash when being revoked access to certain things, while giving them fake access to an empty phone book e.g. would be a good way to circumvent this.
Windows ran fine on a 64 bit architecture in 1996. Perhaps earlier, but that's when I saw it running on a DEC Alpha server. At the time Linux was extremely tricky to port thanks to its origins as a PC operating system, and OpenBSD hadn't yet made a formal release.
But it may be hard to look around the memory space using the code you can fit into a specific buffer under/overrun.
Turning attacks into system crashes is a good thing, because it means the admin will notice something is wrong, and it'll take ages for the attacker to succeed (which means the attacker will probably realise it's pointless and not try, which means no crashes).
I have to agree (and I'm an Android user, and no fan of Apple). Users want security and total convenience, and while technically the permissions side of Android is fine, the average user just wants their funny talking dog app to run - they don't care to look through the permissions list and wonder why it wants to be able to dial numbers and access all their personal data. Similarly, when Microsoft implemented UAC in Windows, people complained about the intrusive pop-ups and would automatically approve them to make them go away, until they were forced to lower the default setting in Windows 7. But you can bet that if they get malware on their Android phone or Windows PC they'll be blaming Google and Microsoft for not preventing it, rather than themselves for agreeing to its installation.
I don't see how there can be a perfect solution though... either you have freedom and have to take responsibility for these risks (knowing that a lot of people won't), or close off the device to anything that's not officially curated (restrictive and not foolproof either). Given the choice, I'll take - and have taken - the former, but I can appreciate that it's not necessarily ideal for the average user. All I can think of is initially exposing devices to a curated version of the Play Store ala Apple but providing a way to access the unrestricted catalogue if you agree to the increased risk, but that starts to make developing for Android look less attractive and would cost Google more.
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.
Support my political activism on Patreon.
Are most iOS applications written in a Java-like language?
No. iOS applications don't need recompilation because they are written in the unmanaged language Objective-C, perhaps with some C++, except for those applications that run mostly inside a UIWebView which are written in JavaScript. The W^X enforced on applications other than Safari's JavaScript interpreter is stricter than that on platforms allowing general recompilation: no page designated for writing can ever switch to being designated for execution, nor vice versa, without being cleared first.