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.
here is an idea why not just use unix permission built into linux? give me sudo privileges by default so i don't have to hack it, and let me worry about the security.
---Saying gnome 3 is better than windows 8 not so much a compliment as it is damning with light praise.
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.
I really wish I had some mod points for you.
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
derp-dee-derp-dee-doo!
jackass
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.
Randomization doesn't make the attack impossible; It simply reduces the number of times it works to some fraction of the original. It's like using a salt on a crypto function: It increases the number of times the attack needs to be performed before it'll work. Although the locations in memory are random, there have to be API calls and such to pull those locations. If your bootstrap code calls those APIs... eventually it'll hit the right offset and your code will run in its entirety, you'll get the locations you need, and the payload can be delivered.
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.
When you're writing malware, you don't have to get 100% of your target... 5% is valuable too. Or even 1%.
#fuckbeta #iamslashdot #dicemustdie
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.
On 32bit processors ASLR is rather pointless IMHO and since AMRv7 (all current chips) is 32bit logical you're not going to to gain much if any real protection.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Well considering ASLR was first implemented on 32 bit systems like OpenBSD, Windows, Linux, etc. I'd say that the people that fucking invented it know a little more than you do.
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.
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 have been doing game hacks (trainers and multiplayer hacks) on Windows for over a decade. Windows - or it's compilers - have always had data and code location randomization. As a result we don't rely on specific code addresses but make our code universally working anywhere. One popular method of establishing this is to rely on fingerprints. Instead of hard coding addresses, you provide fingerprint that finds the right place first. Lets say you have a specific code. Then your fingerprint might be as follows: 90 32 ?? ?? ?? ?? 30 ?? ?? ?? 90 90 90 90 ?? ?? 32 40 4B ?? Then you will run thru the code searching for such piece of code. Anything can be in place of ??, such as other addresses. Sure, you can't hard code anymore.. but your code will be much better after adding this kind of function because then it will also work between all versions of software, even if updates. So basically Google is adding something that other OSes have had for decades and making a huge noise about it, while it actually establishes nothing and even forces hackers to deliver better code. It seems like Google does not know at all what they're doing with their OS.
How did this get modded troll? Someone on google's android team must have a slashdot account...
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.
memory corruption bugs that inevitably crop up in complex pieces of code...
Well, if they didn't use an OS written in C, or they used a static verifier, they wouldn't have that problem.
Address space randomization only protects against inept attackers. If the attacker can get anything running at a low privilege level, and there's an overflow exploit that lets them look into the address space they're attacking, they can find whatever is being moved around.
Address space randomization at best turns attacks into system crashes.
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.
It's mostly a problem for developers as they can't just use nice new features without cutting a huge chunk of user base or coding in feature detection, lazy loading and fallbacks.
Average users don't care for it much as long as they get their Angry Birds and Facebook. Manufacturers don't care for it much as long as users don't care for it much.
If users were leaving brands and platform in droves because lack of updates made their phone useless (for example, because most popular apps require latest OS features), we wouldn't be seeing this. As it is now, most Play Store apps require 2.2, which means users don't care for OS update, which in turn means manufacturers have no incentive to provide updates, which in turn means developers write everything for 2.2, which means users don't care ...
It's the same kind of problem as with IE holding back web developers, or half a decade old consoles and Windows XP's DirectX 9 holding back PC game developers. If you look around, the same circular patternt of "Good enough, so consumers won't upgrade and producers won't move on because consumers won't upgrade" is everywhere, IRL and in software.
I'm all for additional security in all areas, but if they at some point remove the ability to root android phones then they will start to loose some of their appeal. Many cell carriers lock down important functionality in the android platform and its a slap in googles face giving clients crimpled versions of their platform and thus incomplete impressions on just how cool android is. Security should still take priority over worrying about whether or not people can root the device, but I'm hoping for the best of both worlds.
http://interserver.net/
Apple is further than Android. Sure, the app has to ask for permission, but whom does it ask? The end user. The end user is asked to agree to *bunch of things* to get his new app that he just chose out of a gazillion other apps. At that point in time, the end user is determined to get the app on his/her device and is willing to agree to anything because they already decided they want the app. In practice, those explicit permission grants mean nothing because for all practical purposes, over 50% of end users would probably agree to donate their first born child to the developer of the app without even blinking if that was in the click-screen with the grants.
Also, the unique UID per application and the unix filesystem permissions for all apps are usually worthless. Developers tend to set permissions of all their files to 777, which means world readable and executable. That way, they won't get any pesky permission denied errors. That other apps can read and write in their files doesn't matter to them, until someone "hacks" their application they aren't going to change it and Google Play sure isn't going to deny them for it, because Google has no commercial interest in denying apps that aren't malicious but just stupidly bad protected.
No, this is not an Apple Fanboi comment, but a reflection on the state of security android is in at the moment. These two factors combined make Android a total laugh when it comes to security, even if the rest of the framework is getting fairly decent, the end result is abysmal and you should consider any and all data on an average users android phone to be compromised.
I was promised a flying car. Where is my flying car?
I do. My phone is an original Samsung Galaxy S i9000 released in 2010.
Runs a treat. Got it from here.
You can never know everything, and part of what you do know will always be wrong. Perhaps even the most important part.
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.
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.
Security through obfuscation/obscurity is when a company says "It's secure because it's proprietary." Seriously, because they have security experts looking at their implementation and critiquing it, by definition it's not security by obfuscation.
ASLR is a very important OS security mechanism. With DEP, which prevents hackers from simply placing an exploit in the application's own memory and executing that, hackers need to be able to determine where system libraries are in memory, in order to leverage them to execute their exploit code. If they get the memory location wrong, the exploited application will most likely crash (the stack will return to a memory location with unpredictable results). It isn't simply a matter of trying randomly, because they can't.
Basically true while being 100% false.
Only on slashdot.
not to mention, all they had to do was turn it on in the kernel and make sure dalvik worked with it.
Either way, the problem was that messing with permissions like that would break some apps for whatever reason.
It's because the applications don't catch the SecurityException that gets thrown when an application accesses an API that requires a permission that the application doesn't have. This is done on the assumption that the installer will grant all privileges that the application requests, which is true of all official Android releases (and particularly all that come with a lawfully made copy of Google Play Store).
if we had descent permission we could stop super pony free app from phoning home our stolen information.
For one thing, I thought only Parallax Software had Descent permission. For another, if the application weren't allowed to phone home at least every so often, it'd just error out "can't contact high score server" back to the home screen, just like the various Android app stores do while offline.
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.
Actually, you're wrong. On IA-32, a non-executable bit is implemented by using the segmentation features of X86. Data is set to be the whole address space above the lowest data page. Code is set to be everything below the highest code page. In this way, basically, the stack is marked non-executable for no performance impact.
The rest of the address space is both data and code, and can be executed or altered. Memory protections are used to make executable pages non-writable; while non-executable data pages are marked as Supervisor. A TLB fault occurs upon access, in which case the kernel has to assist the TLB load due to lack of permissions in the USER context. The kernel examines the type of fault (Read, Write, Execute) and page permissions; if it's an Execute fault, it throws a General Protection Fault and terminates the program. If it's Read/Write, it instructs the CPU to perform a DTLB load and continue. Once the page is in the DTLB, its context is ignored unless an ITLB fault (on attempt to execute the page) is thrown (in which case the kernel kills the program). Until the DTLB is filled and the page is pushed out, or the DTLB is cleared by a context switch, the program can read/write the data page as normal.
Simple, yes?
Support my political activism on Patreon.
Nor realizing that that means they didn't get one of the most key points of software development: That you never write the same code twice
So how should one design an application for portability to both Windows Phone 7 and another handheld platform without either A. writing the same code twice (WP7 can't run a lot of languages other than C#) or B. paying hundreds of dollars per year to Xamarin?
PHP, which appears to be the only language and community ever to actively hate consistency to the point of working directly against it
I agree with you. However, PHP hangs on in part because entry-level web hosting plans that offer only PHP are often cheaper than plans allowing other, more consistent languages. Case in point: visit this page, click "Linux plan details", and search for "Language Support".
All I can think of is initially exposing devices to a curated version of the Play Store ala Apple
AppsLib tries to do this: it ranks "approved" applications higher than other applications. Amazon Appstore is also a curated store and the default store on Kindle Fire tablets.
iOS works fine without JIT compilers outside of JavaScript in Safari.
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!"
RTFA. It was introduced in 4.0, but the implementation was flawed. It is fixed in 4.1.
Reading the fucking article to gain more insight than was present in the summary? Perish the...oh, yeah, right.
Carry on.
Here, read this paper if you think ASLR on 32bit architectures is worth much of anything....
I'll give you a hint from the Abstract
We conclude that, on 32-bit architectures, the only benet of PaX-like address-space randomization is a small slowdown in worm propagation speed.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
This is security through obscurity
i don't think that means what you think it does.
When you're writing malware, you don't have to get 100% of your target... 5% is valuable too. Or even 1%
1. 100% is much more valuable than 5%
2. the people with non-compromised devices will be much happier.
i spent five minutes thinking and all i got was this crappy sig
yeah there really should be an easy system to undo your own mods.
i don't see how it could be abused, you don't need to get the points back, hell it could even cost an extra point.
the definitely store which comments you've modded which is why you can't mod the same comment twice.
i'm assuming they'd also store what your mod was.
i spent five minutes thinking and all i got was this crappy sig
And if the stack is read-only you basically get 1 instruction, the address for a return/jump/etc.
I think you meant "non-executable". A read-only stack would be nearly useless. (It would at least be practically invulnerable to stack-based buffer overflows, but only because no buffers could be stored on the stack.)
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
While true that ASLR was added in Vista, it is disabled by default because of a bug in the ATI Catalyst driver that causes issues with it.
He used a subscriber account to read the story early, type up a rather lengthy response, and then posted it using a brand-new account. You can tell this because his comment was posted in the same minute as the article, yet clearly took more than one minute to post. Astroturfers seem to use this method to post scathing commentary about company X (Google seems to be the most common), while avoiding the permanent karma hit (and recognition as an astroturfer) to their subscriber account.
It could also just be a troll posing as an astroturfer, and using this method to irritate the community. That distinction is largely irrelevant, however.
Oops, yeah, heh. See my previous post, I meant to refer to ASLR + non-executable stack/heap + read only code pages :)
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.
Thanks for the pointers.
However, I was more interested in Android's direct competitors, i.e. other mobile operating systems. I am certainly aware that desktop/server OSs have had ASLR for quite a while. (Although I don't think MULTICS would have had it... I read that ASLR was only invented in 2001. Maybe it existed earlier but not under that name?)
Yeah, my comment about Apple's head start was _intended_ to draw attention to the way the summary was castigating Google's alleged tardiness, when in reality they're only a handful of months behind their major competition in _mobile_ OS's. I thought the article summary was quite trollish when it was talking about how Google has "finally implemented an industry standard defence" and I was trying to point that out - I wasn't trying to troll myself!
I appear to have been widely misinterpreted, unfortunately. I definitely need to use sarcasm tags more when posting on Slashdot.
I certainly think ASLR is a great thing to have in a widely-deployed OS that tends to hold a lot of valuable user data, and which has a lot of exposure to the web. I'm still curious to know whether BB OS and Windows Phone have any ASLR capability, but it appears that no-one who knows has seen these posts.
For what it's worth, I've done 5 minutes of Googling and haven't found any evidence that WP7 or BBOS _do_ have ASLR. So I'm kind of assuming that they don't (which makes a bit of a mockery of the claim that ASLR is an industry standard). Still, good job Google (and Apple) for actually applying serious security improvements to mobile OS's.
ASLR is commonly used alongside DEP, and it's harder to get a JIT-recompiling virtual machine such as Dalvik working under DEP than to get anything else working under DEP.
Six years in IT industry is eternity.
Then explain why so many businesses are still using a desktop OS from 2002.
are you sure it wasn't emulated 32-bit addressing? 64-bit Alpha Windows 2000 was never widely released. it was dropped in favor of the itanium version.