So, the author says that this attack doesn't rely on precise timing, but I couldn't get this to work at all. The first couple times I tried it, I wasn't even sure that there was a flash of the application, and once I could (I think) see it, there was no chance in hell of doing anything with it. I'm not too worried about this one.

(SIII, 4.1.2)

I couldn't reproduce on a Galaxy SIII either - maybe it never affected the device or they've already patched it (My kernel version is 3.0.31-996085 from Feb 25.)

Interestingly, I've got 3.0.31-861013 from Feb 14, which should be before this exploit was reported. This makes me skeptical that it ever did work on the SIII, as the more I try this, the less convinced I am that I'm actually seeing any flash of an app.

Works on my Verizon SIII (model SCH-I535, Android 4.1.2)

EDIT: I can't get it to work a second time. Weird.

Recognizing that it is not politically correct in these parts to pose this question, I sometimes wonder if the Samsung team (which seems like a highly-skilled, competent team) regrets building on Android...

To be clear: yes, this is a bit of flamebait and a rephrasing of https://news.ycombinator.com/item?id=5404719 .

The thing that rubbed me the wrong way was that we see far too many comments that follow a pretty obvious scheme:

* Criticizing the viability of whole platforms based on generalizing details without good discussions of the whole thing.

* Application bugs are often blamed to a general unfitness of underlying frameworks.

* Tricky interactions of Framework bugs with Applications even more so.

And, even worse:

* Based on the "flavor of the week".

Or: we're all victims of our own perception and we are not willing to recognize it.

For example, No one here really knows why this bug specific happened - it could be that Samsung triggered an Android bug, or they just flat out built something wrong. Its a detail that - by itself - holds absolutely zero information about the Galaxy S line, Android or Samsung.

I believe that both Rails and Android (and almost any other platform) have systematic problems, but rarely anyone ever discusses them, because its far to hard to find people that actually do have enough knowledge and are willing to dig into multiple implementations of the same. Rails is in a pretty obvious phase of downwriting by a lot of people, Android is very well liked by many.

For the record, I am not very attached to both, I maintain a different Ruby web framework and I cannot really get pumped up about mobile stuff.

What makes you wonder that?

FTA:

This does not occur on stock Android from Google. This flaw only seems to be present on Samsung's version of Android. I have only tested it on a Galaxy Note II running 4.1.2 - I believe it should work on Samsung Galaxy SIII. It may work on other devices from Samsung.

I am sure that when theyre not busy cashing checks for billions of dollars every year they look at Nokia and RIM and wish they had tried to build their own platform too.

All the responses to the parent comment are missing the reference. It's a rephrasing of a comment on another post on HN, about Ruby on Rails.

"Recognizing that it is not politically correct in these parts to pose this question, I sometimes wonder if the Github team (which seems like a highly-skilled, competent team) regrets building on Rails." [1]

[1] https://news.ycombinator.com/item?id=5404719

It seems to me that Android is relatively secure. But when third parties start faffing around with it, they make elementary security mistakes.

Samsung should stick to making hardware. Their software is either buggy or gimmicky.

What about this series of repeated flaws which indicate a fundamentally flawed lock-screen architecture makes it seem like the Samsung team involved was highly-skilled?

Note that this is a Samsung lockscreen bypass, not an Android lockscreen bypass.

from r/apple on reddit

http://iphone.appleinsider.com/articles/13/03/19/apple_relea...

"Apple has released the latest update for iOS, version 6.1.3, which fixes a bug that allowed for bypassing of the phone's lockscreen security feature"

"The update fixes an exploit activated by making and then immediately canceling an emergency call on a passcode-locked device. A malicious user with access to the device could use the exploit, plug the device into a computer via USB, and potentially access the data stored on the handset. "

I think it's funny.

Was this a joke about the Github-Ruby thread from before? If so, maybe invest in some sarcasm tags?

"Recognizing that it is not politically correct in these parts to pose this question, I sometimes wonder if the Github team (which seems like a highly-skilled, competent team) regrets building on Rails." [1]

Sarcasm maybe? In which case you don't deserve the downvotes [1] https://news.ycombinator.com/item?id=5404719

Not quite sure which "Samsung team" you are referring to... Would that be the same guys responsible for the /dev/exynos-mem vulnerability?

Android Vanilla is a responsive, fast, beautiful, nearly bug free environment.

Samsung's development teams in virtually every industry is lackluster at best. Their phone and TV UIs are painful to look at, and built with features are often broken or incomplete. They are huge fans of animated loading screens, tacky lit logos, annoying systems sounds, and flashing lights. The fact that their flagship TV ships heavily touting voice commands which almost completely don't work, and visual gestures that absolutely don't work, is pathetic. The cherry on top is anyone trying them, looks like complete tool.

Their screens are industry leading, and their phone hardware are also pretty amazing. I would say the problem is the Samsung dev team, and is not Android.

I've actually had this happen sporadically just unlocking my SIII. Whatever app or homescreen had been on before locking it would flash in for a second or two before going to the lockscreen. Never paid it much attention.

Bet the attack doesn't work on CM10 (Cyanogenmod) which people should be running anyway instead of basic android, it's amazing.

You are correct, this does not affect CM. But you are completely wrong implying having CM protects your device. To get CM you have to unlock your bootloader giving you full access to everything on the device. Unless you explicitly relocked your bootloader after you installed CM your phone is about as wide open as it can get if someone stole it.

Pardon my ignorance, is there another option besides relocking? I believe in the Nexus One days, relocking took quite some time to solve. I'm wondering if that's still the case.

And my last ignorant question, if you relock are there any complications running a custom ROM such as CM? Specifically, on reboot. Thanks.

I cant remember specifically for the Nexus One, but i believe its the same as the modern nexus and samsung devices(devices that provide an official way to unlock).

When you unlock a device it wipes the entire device, so your data would not be at risk.

I do not know if it wipes it when it relocks it, but no it is not a complicated task. All it requires is one command.

"fastboot oem lock" to lock

and

"fastboot oem unlock" to unlock(wipes device).

CM has an option now to encrypt your whole storage?

Does that not help?

I am not sure to be honest. I know of the feature your referring to, its actually a feature of Android 4.1 or 4.2. AFAIK it encrypts your device, if i had to guess this would mean it encrypts the /data partition, idk about removable storage. If i had to guess this data is only encrypted on access while the OS is booted, so yes this should keep your data save from access via recovery or other bootloader.

It doesn't work on basic android(the article clearly states that). Only Samsung's braindead changes to android are the cause of this.

I have yet to see a single instance where Samsung actually improved android with their changes instead of just making it uglier, harder to use and less secure.

A reasonable assumption, yes, given that it's in Samsung's code.

'People' shouldn't all run stock though, the beauty of Android as that people can run what they want (well, mostly, anyway...)

Huge fines are needed for these mistakes (say $100k per exposed user).

These catastrophic mistakes will only stop if a single one can easily bankrupt your company.

EULAs and disclaimers would simply be reworded to protect the company.

Or the company could spin off a subsidiary with no assets, which would produce and licence the software to the parent company.

User education, better QA and timely security updates (for the inevitable mistakes) are what is really needed.

Or companies will stop producing software if a single mistake can easily bankrupt a company.

Your car should be totaled if you go above the speed limit. That's the only way to stop rash drivers from endangering the lives of others.