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."

Comments

How stupid they think hackers are?

[Jellys]

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.

Re:How stupid they think hackers are?

[The MAZZTer]

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.)

Re:How stupid they think hackers are?

[The MAZZTer]

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.

Re:How stupid they think hackers are?

[Anonymous Coward]

So it would be better NOT to have this?

Having a lock won't deter every thief, but it sure does keep out the casual criminal.

And I haven't seen Google make some huge presentation out of having it, either, just a couple of obscure-to-the-general-population (that description actually includes /. btw) sites talking about it.

Get ... over ... yourself.

Re:How stupid they think hackers are?

[bad_fx]

I really wish I had some mod points for you.

Re:How stupid they think hackers are?

[Anonymous Coward]

Google's not making any noise about this, it's someone else. RTFA.

Re:How stupid they think hackers are?

[noh8rz5]

tfs:

memory corruption bugs that inevitably crop up in complex pieces of software

"it's not our fault, it's inevitable! the software is complex, so there's no way to code it properly to prevent obvious holes you can drive a bus thru!" -googdevs

Re:How stupid they think hackers are?

[Anonymous Coward]

derp-dee-derp-dee-doo!

jackass

Re:How stupid they think hackers are?

[jeffb (2.718)]

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.

Re:How stupid they think hackers are?

[Anonymous Coward]

> 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?

[girlintraining]

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%.

Re:How stupid they think hackers are?

[Anonymous Coward]

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.

Thank you so fucking much. The blatant shilling by waggoner-edstrom and burnstmueller sock puppets is what is destroying this once awesome website. WAKE THE FUCK UP GEEK.NET! Taco save us!!!

Re:How stupid they think hackers are?

[afidel]

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.

Re:How stupid they think hackers are?

[Anonymous Coward]

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.

Re:How stupid they think hackers are?

[Anonymous Coward]

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?

[Anonymous Coward]

Why was OP marked troll? Dude may be wrong, but this was a better post than frist.

Re:How stupid they think hackers are?

[Anonymous Coward]

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 stupid they think hackers are?

[cheater512]

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?

[kelemvor4]

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...

Re:How stupid they think hackers are?

[Anonymous Coward]

Let me give you some highlights.

> Windows - or it's compilers - have always had data and code location randomization.

> Implies ASLR is about preventing already executing malicious code to find something, not about cutting down possibilities for malicious code execution

> 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

Yep, knowledgeable and not troll. And you're a smart person successfully outing a Google conspiracy, and your mom is slim, beautiful and doesn't engage in sexual promiscuity. You shouldn't consider suicide, because you're valuable to humanity's gene pool.

Re:How stupid they think hackers are?

[Anonymous Coward]

LMAO! You are fucking clueless.

Re:How stupid they think hackers are?

[Dahamma]

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...

Re:How stupid they think hackers are?

[Dahamma]

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.

Re:How stupid they think hackers are?

[Anonymous Coward]

Yeah dude.. That must be why Android is so "popular" here. .. no wonder Android manufacturers signed up with them. Good call !

Re:How stupid they think hackers are?

[Anonymous Coward]

The stupid is strong with you.

Re:How stupid they think hackers are?

[Anonymous Coward]

tard

Re:How stupid they think hackers are?

[metacell]

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?

[metacell]

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.

Re:How stupid they think hackers are?

[zdzichu]

Vista was released in 2006. Six years in IT industry is eternity. So "always had ASLR" is basically true.

Re:How stupid they think hackers are?

[LizardKing]

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.

Re:How stupid they think hackers are?

[Dog-Cow]

You are stupid, almost beyond belief.

Re:How stupid they think hackers are?

[Dog-Cow]

Basically true while being 100% false.

Only on slashdot.

Re:How stupid they think hackers are?

[ewanm89]

not to mention, all they had to do was turn it on in the kernel and make sure dalvik worked with it.

Re:How stupid they think hackers are?

[bluefoxlucid]

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.

Re:How stupid they think hackers are?

[bluefoxlucid]

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?

Re:How stupid they think hackers are?

[Anonymous Coward]

Statistically, it will stop 99.99985% of attacks; unless the RND is also compromised. But then again, its only intended to stop bruteforce, not more complex attacks. There is a difference between "could be better" and is statistically significant enough to hinder the vast, vast majority of attacks. As is very clearly the case here. Adding 64-bit simply adds a lot more '9's on the end, making it all that much harder. If you believe this is not effective, very clearly you've not considered the statistics even once.

As the GP said above - the original implementations were 32-bit and did NOT require 64-bit addresses spaces - nor did it initially use 64-bit address spaces. In this case, I think its safe to listen to the people who actually implement this rather than you.

Re:How stupid they think hackers are?

[afidel]

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.

Re:How stupid they think hackers are?

[psiclops]

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.

Re:How stupid they think hackers are?

[Anonymous Coward]

You're a game hack developer huh? Wow. You're amazing. Let the adults discuss here.

Re:How stupid they think hackers are?

[psiclops]

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.

Re:How stupid they think hackers are?

[Anonymous Coward]

Linux had ASLR before Windows. Go look up the PaX project, those are the guys that invented the idea and they first implemented it on Linux.

Re:How stupid they think hackers are?

[JesseMcDonald]

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.)

Re:How stupid they think hackers are?

[dan325]

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.

Re:How stupid they think hackers are?

[BenLeeImp]

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.

Re:How stupid they think hackers are?

[Anonymous Coward]

The only thing you've been doing for years is anti-Google FUD under sockpuppet accounts.

Fuck off, bonch.

Re:How stupid they think hackers are?

[Dahamma]

Oops, yeah, heh. See my previous post, I meant to refer to ASLR + non-executable stack/heap + read only code pages :)

Re:How stupid they think hackers are?

[spongman]

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.

Re:How stupid they think hackers are?

[Anonymous Coward]

Heh, I just hit it with 'troll'

+1 headline

[Smallpond]

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.

Re:+1 headline

[Anonymous Coward]

If they don't, then in good Internet tradition, follow up with a nicely offensive slang piece like: “U Jelly, Macfags?". ^^
LOOK AT THE MONKEY!
LOOK AT THE SILLY MONKEY!

The Jelly Bean Luxury

[Anonymous Coward]

who cares....who has 4.1?

Re:The Jelly Bean Luxury

[Anonymous Coward]

who cares....who has 4.1?

Hey troll. Owners of the Galaxy Nexus and the Nexus 7 do. And just as Gingerbread filtered down, so will Jelly Bean and its successors as people buy devices.

Re:The Jelly Bean Luxury

[Anonymous Coward]

Got it today on my nexus in Australia with Telstra

Re:The Jelly Bean Luxury

[Anonymous Coward]

Galaxy Nexus that is.

Re:The Jelly Bean Luxury

[Anonymous Coward]

Why are you worried about it? Every comment by this noh8rz$ account has been disparaging Google and their products. You started at noh8rz months and months ago and as the accounts get modded down into oblivion, you just start another one. Now for the real people on here, one of the best deals going right now is the Galaxy Nexus for 349 dollars direct from Google with...ding ding ding...JellyBean. Now h8 on that, chump.

Re:The Jelly Bean Luxury

[SomePgmr]

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.

Re:The Jelly Bean Luxury

[Anonymous Coward]

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.

Re:The Jelly Bean Luxury

[niftydude]

I do. My phone is an original Samsung Galaxy S i9000 released in 2010.

Runs a treat. Got it from here.

Re:The Jelly Bean Luxury

[SomePgmr]

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.

Re:The Jelly Bean Luxury

[Anonymous Coward]

As pointed out several times on here already, this security is actually in Ice Cream Sandwich, which has a significantly growing user base as the newer phones have it and the older phones are beginning to get upgraded to it. It's just a shitty title/summary that doesn't actually explain what the real deal is.

unix permissions?

[lister king of smeg]

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.

Re:unix permissions?

[oakgrove]

There's a device for that.

Re:unix permissions?

[vistapwns]

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.

Re:unix permissions?

[lister king of smeg]

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.

Re:unix permissions?

[Anonymous Coward]

It is a PHONE. Not a fucking workstation. Every process on Android is run under a different user respecting the permission system built into the Linux kernel. Trying to turn your phone into a desktop is pointless. Just use the desktop when you need to go that far with it. And if you really want to use your phone, install Linux in a chroot and go to town with sudo.

Re:unix permissions?

[lister king of smeg]

no but the issue it security of the devise. patching a memory leak on a browser is like putting bars on all of the windows of your house but leaving the garage door wide open. First shut the gurage door in this case give me control over permissions to my devices so i can control what apps can send home as it is every apps has permissions to everything they can think of wifi, cellular connection, contacts, microphone, etc etc etc. why would joe hacker bother trying to exploit a memory leak when he can just get them to install super free pony coloring game and own the users whole digital life and sell all of their information while serving them adds. or make them buy the add free version of his information stealing pony coloring app. if we had descent permission we could stop super pony free app from phoning home our stolen information.

Re:unix permissions?

[lister king of smeg]

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

Re:unix permissions?

[mr_exit]

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/

Re:unix permissions?

[spire3661]

Its a POCKET COMPUTER, not a workstation.

Re:unix permissions?

[f3rret]

Actually IIRC CM has support to do something like that. Or it was planning to have that feature, I forget.

Either way, the problem was that messing with permissions like that would break some apps for whatever reason.

Re:unix permissions?

[data2]

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.

Re:unix permissions?

[CaptainJeff]

The Unix permissions model that is part of the Linux kernel within Android is used extensively and is central to application isolation within Android. It's just not used as you think it is. Each app runs under its own UID and each app has full permission to its own directories and resources (owner has full control) while no other apps have any permissions to those resources (by default, this can be changed by the app's developers and by you, assuming you have root-level access to your phone).

Re:unix permissions?

[geminidomino]

They have that too. Gave up on CyanogenMod for anything but my Nook (it's the only passable mod for it that I've found) when they made their reasoning clear on why that would never, ever be in the mod itself.

Re:unix permissions?

[data2]

Very cool, thank you

Re:unix permissions?

[farble1670]

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.

if you want root, go root your device. please don't act like it's a good idea is give grandma a rooted device off the shelf.

Re:unix permissions?

[farble1670]

that's exactly why android's permission model requires users to grant the permission before installation. writing an app that behaves reasonably with all possible combinations of permissions either granted or denied by the user is a nightmare.

I love when people try and counter hackers

[GoodNewsJimDotCom]

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.

Re:I love when people try and counter hackers

[Anonymous Coward]

So you're saying the platform is safer without ASLR. Well, damn, why didn't MS think of that before they put it into Windows all those years ago. Who'da thunk it...making your system more secure makes it less safe. By the way, how you been doing after the accident? I heard you hit your head awfully hard (it shows).

Re:I love when people try and counter hackers

[Anonymous Coward]

I was with you right up to your sig where you revealed you've suffered repeated mental breakdowns.

Re:I love when people try and counter hackers

[Anonymous Coward]

You fucking IDIOT. This is not a Google press release you fucking retard. This is some security researcher tooting his horn and talking about what Google did months and months ago in Ice Cream Sandwich. Yes, ASLR was implemented in ICS you fucking moron. Nice shill attempt though.

Re:I love when people try and counter hackers

[mjwx]

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.
 

Thats why all hackers target Linux/Unix and leave windows alone, because we all know Windows is nowhere near as secure (or can be as secured) as Linux. Therefore according to your theory, because windows is easy to hack it does not attract hackers.

oh wait...

Re:I love when people try and counter hackers

[GoodNewsJimDotCom]

Your logic does not pertain to my argument.
I merely say that you should be secure, and not boast about being secure.
You're talking about a strawman where easy to hack systems are hacked more. Of course easy to hack systems are going to be hacked more. My argument wasn't arguing against that.

I just say that the minute you start boasting about your security, you draw more people in to try and hack it. Unless you're a sicko ready to pursue an arms race to "Hacker Armageddon", you never boast about your device or code being unhackable.

Re:I love when people try and counter hackers

[Anonymous Coward]

Google should have implemented the new security measures discretely.

ASLR's not a 'new' security measure. It's a well known technique that's been around for nearly a decade: http://en.wikipedia.org/wiki/Address_space_layout_randomization

Also, security doesn't work how you suggest it works. Android's already an open source system, so hackers will be able to figure out how things work anyway.

Re:I love when people try and counter hackers

[Jesus_666]

Google never did that. Someone external to Google pointed out that Google improved on their implementation of some well-known measures. Which he probably learned due to Google not exactly keeping the Android internals a secret, Android being open source. If you look at TFA it's not "Google says that Android is unhackable" but "someone from an IT security company praises Google for improving on the ineffectual ASLR found in the last Android release".

That's a bit like saying that Microsoft boasts about Windows 8 coming with a direct computer-to-brain interface when actually a few PC mags said that they like Metro. (Granted, I haven't seen any instances of that, either.)

Re:I love when people try and counter hackers

[Anonymous Coward]

Its new to Apple

Re:I love when people try and counter hackers

[Anonymous Coward]

Its new to Apple

Yeah, but they still had a working implementation in iOS for over a year before Android did.

Re:I love when people try and counter hackers

[KingBenny]

cat people are not dogs, i think it's not just because they want to, it's because they have to, like an olympic athlete needs to push his or her limits to truly understand themselves. maybe it's just the same kind of self-exploration present in most healthy people, the need to be challenged and the need to know

Re:I love when people try and counter hackers

[Dabido]

I agree. But the other option, if the headlines keep telling people you're getting hacked then you need to at least show you are doing something. A case of, if you don't tell people you're fixing things they go to the competition, if you do, you attract hackers, but at least you are still selling stuff and hopefully keeping most of those hackers out at the same time ready for the next evolution in security.

4.2 Jelly Baby

[Ukab the Great]

Will be hackable with a sonic screwdriver.

Re:4.2 Jelly Baby

[Anonymous Coward]

I'm fairly sure that i'm not the only one to get the Tom Baker reference.

Re:4.2 Jelly Baby

[CaptainJeff]

This is why 4.3 will be made of wood. Sonic screwdrivers don't work on wood.

ASLR is a good thing but...

[lennier]

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:ASLR is a good thing but...

[Jeremi]

Isn't the impossibility of memory corruption supposed to be one of the benefits of Java (and other managed-code languages too of course)?

Re:ASLR is a good thing but...

[phantomfive]

Do you have a solution? Because I really want to know it. Really, writing software is something I do for a living.

Re:ASLR is a good thing but...

[DNS-and-BIND]

It's because we don't have professional standards for software engineers the same way as we have for other types of engineers. Software is still in the "bridge collapse" phase. At one time, anyone could build a bridge. You know what happened? A lot of them fell down, and that was just considered normal. Eventually, society got fed up with that crap and made standards, with jail time for violators.

I've tried suggesting that software should be held to the same standards - oh, you should have seen the looks I got. It would be TOO EXPENSIVE, they screamed. It would TAKE FOREVER, they whined. It wouldn't crash, I replied. Who cares about that shit anyway, they scoffed. We're here to do low-quality work at the lowest price...you think we're building this software to last?

Re:ASLR is a good thing but...

[Anonymous Coward]

use a language that treats pointers as opaque immutable objects

tada!

Re:ASLR is a good thing but...

[Anonymous Coward]

I've tried suggesting that software should be held to the same standards - oh, you should have seen the looks I got.

I've worked with gizmos built for an industry where by law the software has to follow a complex development and testing process with a stack of paperwork six miles high to prove that it's certified for use. The end result is bugs don't get fixed because the manufacturers can't afford to rerun the certification process. Worse than that, even when the bugs do get fixed, end-users don't want to install the new software because they've learned to work around the old bugs and don't want to have to deal with new ones.

You end up with everyone trying to implement workarounds for other people's bugs and a lot of 'secret' knowledge around the industry; I say to a manufacturer 'I sent this message to your Gizmo X and it crashed' and they say 'yes, don't do that because if you do that it crashes'.

It's insane. And anyone who suggests that all software should be developed that way is a retard.

Re:ASLR is a good thing but...

[Anonymous Coward]

Managed languages still have memory corruption exploits even though they try to protect against them.

The problem with computer security is that the more secure you make your code, the worse it will perform because it will be running sanity checks instead of doing the work you want it to ultimately accomplish. As computer hardware gets faster, security is becoming much more affordable in terms of performance, but people still tend to care more about performance than security. In another 20 years even our mobile devices should have such extraordinary performance that will allow software security to flourish without hindering perceived performance.

Re:ASLR is a good thing but...

[Drishmung]

use a language that treats pointers as opaque immutable objects

tada!

That helps, but using hardware that treats them that way is better.

Or running in a sandbox that enforces descriptor protocols.

For the TL;DR, the link describes an architecture---still in use and now implemented on x86 processors---where buffer overflow is impossible.

Re:ASLR is a good thing but...

[Drishmung]

And not all hardware followed GP's model either.

I remember a TV show about how the Russians built the Proton rockets. Instead of modeling, testing, checking and being safety conscious, they built the rocket, tested it---and it blew up. So they did it again. And it blew up, again. So they did it again. And again. And again. Until it worked. Net result was a booster more powerful than the Saturn V (AFAIK). Quite a different mode of working.

Along the way they also learned that their observation bunkers were too close to the rocket and not as blast proof as they had hoped. I'm not saying that this is necessarily the best way of working, just that there are other ways to do things if your values are somewhat different.

Re:ASLR is a good thing but...

[Confusador]

Not that the Soviets didn't do any modelling and testing, but your analysis of their method overall isn't wrong - except that they never accomplished anything like the Saturn V. Even a modern Proton-M is only about 1/6 as powerful. Their N1, which was Saturn V class, blew up all 4 times they tested it and then they ran out of money. The method works with small things that you can afford to build a bunch of times, but with big expensive things it starts to be cheaper to just do the testing.

Re:ASLR is a good thing but...

[f3rret]

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".

I don't get what is so sad about this. It seems to me like people have realized that mistakes can and do happen and the exact nature of a mistake in this sort of context is often unpredictable, so you can either roll out patches after the error has been discovered (and a number of devices have been hacked) or you can build in measures that makes the system fault tolerant.

Of course the ideal situation is one where there are no bugs ever and we can full predict every single interaction between every single line of code and see any emergent bugs way in advance. This, however, is not going to happen, we might as well accept this; this is the same reason why cars have airbags and seat belts, the ideal situation is that no-one ever crashes, but sometimes people crash and when that happens it is much better to have airbags and seat belts than not having them.

Re:ASLR is a good thing but...

[metacell]

Who cares about that shit anyway, they scoffed. We're here to do low-quality work at the lowest price...you think we're building this software to last?

Precisely. Who's still going to use programs written in Cobol in the year 2000?

Re:ASLR is a good thing but...

[f3rret]

And not all hardware followed GP's model either.

I remember a TV show about how the Russians built the Proton rockets. Instead of modeling, testing, checking and being safety conscious, they built the rocket, tested it---and it blew up. So they did it again. And it blew up, again. So they did it again. And again. And again. Until it worked. Net result was a booster more powerful than the Saturn V (AFAIK). Quite a different mode of working.

Along the way they also learned that their observation bunkers were too close to the rocket and not as blast proof as they had hoped. I'm not saying that this is necessarily the best way of working, just that there are other ways to do things if your values are somewhat different.

I love the Soviets.

Re:ASLR is a good thing but...

[metacell]

I think the problem is trying to standardise and certify things which can't be.

We should start with the small things which can be standardised. For example, every programmer should know how to sanitise database inputs from the user, and check that buffers can't overflow, and always apply that knowledge if they want to be considered competent.

Re:ASLR is a good thing but...

[dkf]

It's because we don't have professional standards for software engineers the same way as we have for other types of engineers. Software is still in the "bridge collapse" phase. At one time, anyone could build a bridge. You know what happened? A lot of them fell down, and that was just considered normal. Eventually, society got fed up with that crap and made standards, with jail time for violators.

I see you're advocating a large increase to the cost of software for very little gain in actual reliability. Any proper engineer (or True Scotsman) would know that it is important to balance cost and benefit; for a significant fraction of applications, that balance is firmly towards the cheap end. Guess what? Most of the cheap software is also perfectly fine for its purpose after a few iterations. (Well, that's true if we exclude anything written in PHP, which appears to be the only language and community ever to actively hate consistency to the point of working directly against it.)

Re:ASLR is a good thing but...

[gbjbaanb]

is that the case though? As CPUs get faster, they require tricks such as cache throughput to keep them running at top speed. Putting code that stops that (eg security code) in there will kill performance.

Also, more security code has a tendency to grow rather large with various side-effects on perf (eg reading from file all the time if you're virus checking everything, so its no longer a write to disk, its a write + read).

This is one of the reasons modern OSs with their super-computer CPUs perform about as fast as the old computers we used to use. Too many layers of stuff. Now sure, we get more features out of it, so its understandable what we've traded off, but don't assume that faster system lets you get away with adding more code, even security code, for free.

Re:ASLR is a good thing but...

[Drishmung]

Thanks for reminding me. Yes, the Proton is a wonderfully efficient rocket, but it was the N1 which was the super Saturn V. However, as I recall, they did not so much run out of money as run out of Sergei Korolev, the leader of the N1 program. After his death, the N1 program never recovered and was shut down.

Re:ASLR is a good thing but...

[bluefoxlucid]

eg reading from file all the time if you're virus checking everything

I keep forgetting I was writing a library to track and cache this because all vendor AV is shitty. It's ridicuolously easy to get right.

Re:ASLR is a good thing but...

[tlhIngan]

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".

How is this an admission that memory corruption is inevitable?

I see it as defense in depth - the application is the first line of defense against memory corruption (usually caused intentionally). If that wall fails, the OS has a wall of its own to help protect the system as well.

A well-written program would check its inputs, but it's possible that it can fail (it's written by humans, after all), and it's far better to have the OS protect itself than not.

It's like how any network puts up firewalls - the individual servers should be hardened against attack, but it doesn't hurt to put up another layer of security on top of that.

And face it - most developers write crap now and again - either due to pressures of time or "get it working" blocker bugs and are vulnerable to taking a shortcut now and again. Want an illustration of this? See how many programs broke under Windows Vista (which actually enforced many rules that were already in place but most developers skirted and got away with breaking). Or anytime Apple releases a new OS - application breakages between OS X versions (or even Classic MacOS) are legendary. Hell, Microsoft has to often insert bugs in their code as some critical application or other rely on them to function. (Ever wonder why Explorer's top-level window is called "Program Manager" still? Or why "C:\Program Files" sometimes appears after installing a program on a non-English version of Windows?).

It's adapting to the reality of the world. Developers are far from perfect and often cheat. Users rarely if ever read dialogs (see Dancing Pigs aka Dancing Bunnies).

Good start

[Anonymous Coward]

Now just make it harder for the malware installed by the carriers and manufacturers, and you might have something.

Dedication

[Anonymous Coward]

ASLR won't stop everyone.

Can't WAIT to get my Nexus 7

[Anonymous Coward]

This shitty Kindle Fire is going to hand-me-down city and my iPad is getting nervous. Everything I hear about the Nexus 7 and Jelly bean has me extremely excited!

This doesn't affect the most important issues

[johndoe42]

It seems like the big vulneraibilites in mobile platforms these days involve apps doing things they shouldn't. Android is, for the most part, way ahead of Apple in terms of technical mitigations. Android sandboxes apps with explicit permission grants. Apple just vets them, incompletely. iOS also seems vulnerable to odd things, like this. Apparently executing unsigned code on iOS, if you can pull it off, sidesteps part of the sandbox. Android is based on the assumption that any app can execute unsigned code and it still tries to be secure.

Oberheide not so positive on Android Bouncer

[chebucto]

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?

Re:Oberheide not so positive on Android Bouncer

[Anonymous Coward]

Look, fundamentally you have two choices.

1) Software is not reviewed by humans before it enters your app market. Result: you get malware in your app market.

2) Software is reviewed and possibly rejected by humans before it enters your app market. Result: all apps are delayed into the market, apps are rejected for arbitrary, non-malware reasons by assholes, and oh yeah, you still get malware in your app market but maybe a little less of it.

Re:Oberheide not so positive on Android Bouncer

[chebucto]

My apologies.

Re:Oberheide not so positive on Android Bouncer

[Anonymous Coward]

...but maybe a little less of it.

no, a ridiculously large amount less.

Re:Oberheide not so positive on Android Bouncer

[Anonymous Coward]

Statistics to back this up, please? Oh, you don't have any? Well then STFU.

Re:How does this compare to the competition?

[Anonymous Coward]

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!"

Is this similar to ASL

[Anonymous Coward]

http://xkcd.com/380/

What's going on here?

[93 Escort Wagon]

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.

Re:What's going on here?

[Anonymous Coward]

I'm pretty sure that's just one overactive AC. He's got the same typing patterns in every post and everything.

I wonder which of us he will call "numbnutz" first?

Re:What's going on here?

[raftpeople]

Thank you kind sir for that excellent recommendation. However, I am embarrassed to admit that I don't understand how they could be sitting in the back seat while also driving the vehicle over a cliff.

Could you perhaps provide a sketch of your plan so we can better understand?

Re:What's going on here?

[Anonymous Coward]

numbnutz

Re:What's going on here?

[Anonymous Coward]

Please don't feed the trolls.

Re:What's going on here?

[f3rret]

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.

Dude, is this your first time on the internet?

It's pretty much immutable fact that any argument that does not involve profanity and/or the questioning of the original posters sexuality is not going to be read or replied to.

Welcome to the internet, everyone here are assholes.

Simple Minded Question

[NicknamesAreStupid]

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?

Re:Simple Minded Question

[Anonymous Coward]

typed registers are more useful for this problem. harvard machines use two memory interfaces, which preclude any multiplexing gains
in both bandwidth and capacity.

i guess you could divide the address space, but the X bit does that perfectly well.

Re:Simple Minded Question

[wiredlogic]

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:Simple Minded Question

[Anonymous Coward]

Pure Harvard Architecture doesn't work too well in real life. There are often Modified Harvard Architecture to provide access across the memory space.
Sometimes the OS so need to treat code as data too. e.g. OS load in code from a file system into RAM.

Re:Simple Minded Question

[Anonymous Coward]

So then separate *all* the segments. No spillage possible.

But hey, the buffer over-/underrun problem was solved a loooong time ago. It's only that some idiots still stick to outdated languages where it wasn't because it's "faster"... and then go, and implement a slower solution of the same thing that's done in more modern languages... and yet still get over-/underruns because their reinvention of the wheel is still in its infancy.

Re:Simple Minded Question

[multipartmixed]

JIT compilers are necessary for today's workloads. These pretty much require that you are allowed to execute code you just wrote to your data segment.

Inept programming

[Animats]

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.

Re:Inept programming

[metacell]

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).

Re:Inept programming

[farble1670]

Address space randomization at best turns attacks into system crashes.

right, and after a newly installed app crashes, how many times do you keep re-starting it? or do you just uninstall it and install one of the other 1k apps that do the same thing?

seems like a pretty useful result to me.

Re:How does this compare to the competition?

[Anonymous Coward]

If you are curious about security, and which OS was first, perhaps you should look at OpenBSD and Linux (or, to be more specific, grsecurity, SELinux, AppArmor, TOMOYO, etc). If you wish to dig further, there's always MULTICS.

Re:How does this compare to the competition?

[buddyglass]

So, Google has now implemented ASLR in Android. According to Wikipedia, it's been in iOS since 4.3, which came out March 2011, so that's what, a 16 month head start for Apple?

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.

As long as they dont make it impossible to root.

[detain]

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.

Still not fixed

[Anonymous Coward]

This is not the problem with Android. The problem is those 5/5 star apps with "WOW Super I like this a lot" comments for several pages for malware. And the fact that devs are not pushed to explain why they need this and that phone feature (and obviously no control from Google).

In practice

[dutchwhizzman]

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.

Re:In practice

[Anonymous Coward]

You've never actually used Android have you?

Re:In practice

[Mithent]

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.

ASLR != security through obfuscation/obscurity

[pj81381]

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.

Applications don't catch SecurityException

[tepples]

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).

No phone home? No play.

[tepples]

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.

Sounds like a cool concept

[nhat11]

I can try to be a cynic and think that someone will find a work around this concept but I always enjoy seeing new security concepts like this pop up to see how effective it is or not.

Writing the same code twice

[tepples]

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?

Inconsistent languages are cheaper to use

[tepples]

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".

AppsLib and Amazon Appstore

[tepples]

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 without JIT

[tepples]

iOS works fine without JIT compilers outside of JavaScript in Safari.

Re:iOS without JIT

[multipartmixed]

Are most iOS applications written in a Java-like language?

RTFA

[Anonymous Coward]

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.

Re:How does this compare to the competition?

[Anonymous Coward]

And OSX was the last of the major desktop OS's to implement ASLR. Linux has had it since 2000. Windows had it by 2005. OSX only had a partial implementation with Leopard.

Re:How does this compare to the competition?

[Anonymous Coward]

Good confirmation that android copied iOS

I like beans

[Anonymous Coward]

Who would've thought they would turn jelly beans into Androids.
What's wrong with the world. I don't want to hack no goddamn Androids.
Give me my jelly beans back! What the hell am I going to do with Androids?

Re:AKA

[Anonymous Coward]

Mods are bitchy today...

1. Doesn't deserve -1. Doesn't deserve a 5 by any means, but this is a true statement. 1 is appropriate. 0 is as well. But -1 is stupid.

2. Gentoo Hardened, as the OP calls it (always called it Hardened Gentoo myself) actually entails more than the ASLR. The ASLR is a definite factor in it, however, so it is still more relevant than some of the trolls that get up-modded on this...

Objective-C

[tepples]

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.

Re:How does this compare to the competition?

[sapphire wyvern]

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?)

Re:How does this compare to the competition?

[sapphire wyvern]

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 and DEP

[tepples]

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.

Re:ASLR and DEP

[ewanm89]

Yes, which is why it wasn't on 'till ICS. I was just pointing out that there is some inherent support there anyway.

Businesses still use ten-year-old Windows XP

[tepples]

Six years in IT industry is eternity.

Then explain why so many businesses are still using a desktop OS from 2002.