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

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

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

[slo]

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

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