Android Lollipop Can Be Hacked With Very Long Password

Complex passwords are the way to beat some attacks, but for phones running the latest version of Android, that's not necessarily so: puddingebola writes with an excerpt from an article at CNN: Locked phones require a passcode. But there's a way to get around that. Just type in an insanely long password. That overloads the computer, which redirects you to the phone's home screen. It's a time-consuming hack, but it's actually easy to pull off. In a report published Tuesday, computer security researcher John Gordon documented the vulnerability and posted a video of the hack. It only affects smartphones using the latest version of the Android operating system, Lollipop.

Comments

Article is bullshit

[bluefoxlucid]

That's impossible. It's Java! Java can't have security holes! Everyone knows you don't write C because C has buffer overflows and can cause security problems when you paste in very long strings, and that NEVER happens with Java! Java is perfect! Everything you write in Java is perfectly secure! Ask any Java programmer!

Re:Article is bullshit

[benjymouse]

Nothing to do with java. Buffer overflows are quite possible with java, but this problem has everything to do with shitty coding, not the implementation language.

No, but this problem has everything to do with shitty operating system design. The login "screen" should not just be an application that maximizes it's screen to cover the UIs of all other application. That is a naïve implementation, and it opens the supposed security feature up to all kinds of attacks, including shatter attacks and more. Not to mention that an application crash will cause the OS to clean up and close the "blocking" window.

Google should take a cue from Windows and make the login screen a totally separate "desktop" which is completely isolated from the "user" desktop. Switching between the two should be a privileged operation, one that can only be executed by trusted login applications. This way a mere exception will not cause the "login" program to crash, close and reveal the user desktop.

Re:Article is bullshit

[Greyfox]

Java was supposed to protect you from shitty coding. "Oh, use Java," they said, "and you'll never have to worry about memory management or buffer overflows again!" It's true. They said that. They said you could write your program once and run it everywhere. They said you could use Java and hire chimpanzees to do you programming for you.

All those promises only turned out to be true-ish. The chimpanzee quota for most teams actually remained fairly consistent. Turns out a lot of companies were hiring chimpanzees before Java came along. Some of the chimpanzees tried to use Java for system-level programming, and it turned out to not be very good at that. While it was technically true that you didn't have to worry about memory management anymore, if you didn't, you mostly handled your server running out of memory and crashing every few days by rebooting it every couple of days. Logs became a morass of unhandled and permanently ignored exceptions. I often start a new job, look in their logs directory and find gigabytes of exceptions that no one ever looked at.

But you know, it's still better! Because now instead of most programs being giant masses of functions that reimplement system API commands and never take responsibility for any action, they're now giant masses of objects that reimplement system API commands and never take responsibility for any action. Some of them just pass messages around from service to service, none of which anyone truly understands since the system designer was laid off years earlier.

Arguably yeah, implementation language doesn't make a difference. All those teams could have written shitty code and poorly designed systems no matter what language they were using. The implementation language just makes it easier to operate without any discipline and maintain the illusion that they're competent at what they're doing.

Re:Article is bullshit

[Anonymous Coward]

Windows' login screen isn't on a separate desktop. It's the only desktop.

The boot process hands control to the kernel loader (ntldr), which starts the kernel (ntoskrnl and kernel32), which starts the service control manager (scm), which starts winlogon.exe, which calls security account manager (sam) to authenticate and then spawns instances of the local security authority (lsass) for each user that logs on. The lsass process, in turn, hosts virtual desktops for the user. Usually there are 2 virtual desktops per user: the regular visible one and the "secure" one that is only used for UAC prompts. Everything within those virtual desktops runs at the mercy of lsass.

So you basically have the right idea, but described it the way Unix-based systems do it. Instead, Windows' nested/hosted startup process requires less plumbing than the method you describe. You don't need to protect the log-in program from "untrusted" execution if it's only allowed to run once (a simple mutex can handle enforcement) and it runs from boot and hosts everything in userspace. It's basically the kernel's userspace process supervisor.

Re:Article is bullshit

[AC-x]

Ah but you see Java has saved the day, for instead of a dangerous code execution buffer overflow condition the program simply quits out with a safe exception! :)

Re:Article is bullshit

[tnk1]

I'm not totally against Java, but having worked with it since it was released 20 or so years ago, I note that Java was touted as a language/VM/bytecode/whatever where you didn't need to worry about memory management aside from some tuning.

The reality is that Java saves you from having to write your own MM, but that's only helpful if their memory manager is actually better than something you could have written for yourself. Initially, the MM was nowhere near as good as it is today, although it was clearly "adequate". Still, you can do better even today, if you wanted to put the time into it.

What happened is that, for years, we just got used to restarting java apps when they acted poorly, and Operations threw up their hands and gave up trying to get development to actually catch exceptions when they were thrown. Logs full of unhandled exceptions have been normal for more than a decade now.

Java does have good points in comparison to C, but it is very easy to code junk in Java that works enough so that it gets released, which increases productivity, at the cost of well designed applications. That's why it is so popular, especially with the business.

Hardware Access

[Barny]

Yeah, if you have hardware access to a device you own it. Nothing new to see.

Re:Hardware Access

[bill_mcgonigle]

Yeah, if you have hardware access to a device you own it. Nothing new to see.

Really? I'd love to bypass the bootloader on MY Verizon-compatible Kitkat GS4. Please post links.

Re:Hardware Access

[Wrath0fb0b]

Yeah, if you have hardware access to a device you own it. Nothing new to see.

That's actually not true on iOS where the unlock code actually forms part of the master key from which filesystem keys are derived. So hardware access without the unlock code nets you nothing. Of course, with a 4-digit code it's only a few days to try all 10000 of them, but users can a complex passcode with sufficient entropy to make brute force impractical.

Re: Hardware Access

[RavenLrD20k]

Samsung Galaxy S5 owner here. Although I use the fingerprint scanner for a lockscreen, it has the ability to use a backup password instead. The password field does not allow pasting and typing into the field only allows 16 characters maximum; everything above that does not get entered in the field. I've also just switched to password entry as the primary locking mechanism to the same result. Cannot paste and field only accepts 16 characters.

What is old is new

[goombah99]

early versions of mac OSX had a similar problem. 10,000 character password entries would unlock the system. Entering these was aided because the password field accepted emacs key commands (like every other field on a mac) so repeated ctrl-a ctrl-k ctrl-y ctrl-y ctrl-y quickly got you to the passwrd field overload point.

Re:What is old is new

[Tough Love]

The metaproblem here is that Google is less competent than they imagine to develop Android by themselves as they do. The short form of that is one word: hubris.

Re:What is old is new

[macs4all]

early versions of mac OSX had a similar problem. 10,000 character password entries would unlock the system. Entering these was aided because the password field accepted emacs key commands (like every other field on a mac) so repeated ctrl-a ctrl-k ctrl-y ctrl-y ctrl-y quickly got you to the passwrd field overload point.

What versions? One of the Developer Previews?

Honestly, not only have I never heard of this vulnerability in OS X; but I couldn't find it on Google, nor, more importantly, could I find a "CVE" Reference to that alleged vulnerability, either. In fact, the CVE list only shows 92 Vulnerabilities for OS X from 2001 to present (and the vast majority being ranked level "2.1" on a scale of 2.0 to 2.99), as compared to 481 for Windows 7, 221 for Windows 8, 169 for Windows 8.1, and (drumroll please) 29 already for Windows 10 (even though it has only been released for a little over a month). Even more disturbingly, out of the 29 Windows 10 vulnerabilities, MOST of them are REALLY serious (levels 7 to 9).

Re:What is old is new

[slo]

Googling, I found this. It sounds like the screen lock vulnerability described.

Re:What is old is new

[Hognoxious]

The man is dead, but his reality distortion field lives on.

Re:What is old is new

[macs4all]

Not the original poster, and it was a bit hard to find, but there's this: https://www.securemac.com/maco...

I remember a slashdot discussion about it years ago as well.

Ok, well now I remember it; but according to this article (and the comments following it), this is MUCH different than the Lollipop vulnerability:

1. It is only the SCREENSAVER-lock that is affected. The regular OS X Login Screen CANNOT be bypassed in this manner! BIG difference!

2. You must know the USERNAME of an ADMINISTRATOR Account; regular (non-Admin) Users CANNOT use this vulnerability to gain unlock the screensaver. Again, BIG Difference!

3. This has been fixed for aeons.

Re:What is old is new

[Tough Love]

I don't need further proof of Google's incompetence but apparently some people do.

Re:What is old is new

[goombah99]

Actually I believe that android's phone lock is actually a screen saver lock. They just have an app running that covers the screen rather than an actual login screen.

Comment removed

[account_deleted]

Comment removed based on user account deletion

pin code not vulnerable

[sociocapitalist]

Only works against passwords and only in certain cases.

Does not work against pin codes or swipes.

Re:pin code not vulnerable

[asylumx]

You can't swipe to a non-adjacent point

Yes you can. My passcode has this on my android craplet at home. It's just difficult because if you pass over another point to get there it will add the other point too. Since it is similar to a keypad, all you do is go for example from the 9 position to the 4 position (corner on one side to middle on opposite side) without crossing the center point. They are not adjacent, yet you can use them.

Re:pin code not vulnerable

[PostPhil]

I think that was the point being made: it's not about the physical motion of "swiping", the problem is that the pattern is forced to be a contiguous line at all.

Whether I tap two corners and it adds the middle point automatically, or whether I swipe from one corner to the other, it doesn't matter because the problem is the same: this strategy reduces the total possible count of unique patterns.

The better implementation would be for the pattern to be detected as a sequence of activated points, where those points don't have to be part of a contiguous line, and the same point can still be reused later in the sequence. Really it would be better if each point simply flashed briefly when activated rather than using a line, because a line pattern is easy for someone across a room to be able to recognize. At the same time, while a tap on a point activates it, swiping motions should still work too, in case people still prefer their pattern to be contiguous.

Both preferences accommodated for, yet the total possible unique combinations goes up. Problem solved.

ARE YOU LISTENING, GOOGLE?

Re:Breaking security

[circletimessquare]

good response. there is indeed obscure, difficult, fleeting, technically sophisticated, damage limited security breaches, and "oh my fucking god how could you screw up so badly" security breaches that any idiot can perform to get full access

getting the home screen after punching in a crazy long password is a really embarrassing fail on google's part

reminds me of "hacking" windows 98 security:

http://imgur.com/gallery/fqjnK

And it has been fixed

[necro81]

The vulnerability was disclosed to Google, who has developed a patch, which Google released last week. So, it makes for a funny story, and a teachable moment, but does not necessarily mean OMG-We'z-Been-Hax0red!

Re:And it has been fixed

[ITRambo]

I'm pretty sure that most users will not get the patch for a very long time, if ever, due to carriers not caring one bit about updating in a timely manner.

Re:And it has been fixed

[Anonymous Coward]

The hack works for extremely large thumbs.

Re:And it has been fixed

[Carewolf]

If they have a carrier that doesn't care about updates they wouldn't have the very latest android version (the one affected) the first place.

Re:And it has been fixed

[Moof123]

The simple fix would be to make them liable for any break-ins for known security issues not patched within 30 days of availability for phones sold in the last 3 years.

Shipping already orphaned phones is awful. Shipping a phone with vulnerabilities that will never get fixed should be criminal.

I'm in the market to replace my phone, and it is just a sea of crap to wade through. It is very hard as a consumer to figure out how much crapware there is on a phone, or what the odds of ever getting an update are, or if the update will just be extra crapware that fills up the meager remaining on-board storage. I hate the idea of throwing money at Apple's walled garden, but compared to Android's dystopian Wild West (Westworld?) it is not looking too bad these days.

Progress in computing

[thrig]

It's like gets(3), only different!

Re:Novermber,2014 called

[Scoth]

In a past life I led UAT/QA testing teams, and I mostly blame poor fail state handling with a fair amount of positive-result-only testing. A lot of bits are coded such that they really only handle "correct" data, and anything else doesn't get handled properly or at all. On top of that, plenty of test case scenarios either only test that things work properly when used properly, or for things that include fail states that they still only really test "correct" usage. I used to get teased a fair amount for doing things like pasting huge amounts of data in fields (just for bugs like this one), or uploading images to csv-expecting text-based importers, or clicking buttons as fast as I could when it was only expecting a single click, but I found all kinds of weird bugs that way. My favorite, and relevant to this, was when I discovered that entering in a massive block of text on the customer account management site's Add Email Mailbox wizard would crash the entire customer management site systemwide. That one got fixed pretty quickly.

Re:Speaking of OLD

[jason.sweet]

Maybe you could put your phone down, and make my fucking burger.