from Hacker News

To hack an Android phone, just type in a really long password

by chetangole on 9/21/15, 7:09 AM with 143 comments

• by mehrdada on 9/21/15, 8:36 AM

  This can happen only because of a design flaw in the security architecture of Android (L). Unlike iOS and like traditional PCs, the disk encryption key is always in memory when the device is booted and nothing is really protected if you get a device in that state. It's an all-or-nothing proposition. On iOS, there are different encryption keys that are used to protect different classes of information. Specifically, when an iOS device is locked, the operating system loses a key that can decrypt files that are of a certain protection class that are not supposed to be readable when the device is locked. Only by entering the password when unlocking the device (or reloading it from Touch ID memory), that key can be derived again. The effect is, for example, all your mail can be protected and rendered unreadable while the device is locked.

  With this security architecture, no bug in the password "gatekeeper UI" can lead to you being able to read the protected information if the device gets locked successfully.

• by ngcazz on 9/21/15, 10:32 AM

  Only thing that comes in my mind... http://i.imgur.com/rG0p0b2.gif

• by junto on 9/21/15, 10:41 AM

  There was a small and relatively unsuccessful F1 racing team around about 10 years ago, who's name I shall not say here. Internally such teams were known as "pit dodgers".

  When it came to the design of their gearbox, the work was outsourced (as much of it is in F1 unless you are Ferrari).

  The primary gearbox designer did most of the work, however reverse gear proved to be a problem, but rather than fix the problem, it was left to the junior designer who couldn't solve it either, who also left it pretty much unfunctional. This was based on the concept that:

  a) Reverse is rarely (if ever needed) (sidenote: disqualified if used in the pits during a race)

  b) The "pit dodger" team was unlikely to last the entire race anyway, so the gearbox didn't need to standup to a full race duration anyway. The effort put in to designing the components (i.e. precision) can be reduced to match the expectation of success and failure rate of other third party components. Design and production time can be saved and extra profit made.

  Thus lies the lesson of the emergency call feature, or any other feature that designers feel don't really require that much attention because they are rarely used. These features are often handed to junior developers and engineers, because of the fact that people have a tendency to deem lesser-used features as unimportant.

  Which is fine of course until you have an emergency and you desparately need to make that emergency call because your, or someone else's life, depends on it. Or you need to reverse out of the way of a damn F1 car coming towards you at 150mph down a straight and you are sitting in the middle of the track. WTF, reverse doesn't engage....oh shiiiiiiit....

  TLDR: Features that are very infrequently used are not always the features of least importance.

• by tombrossman on 9/21/15, 8:13 AM

  Note this is for password-protected phones only, PIN and pattern protected phones not affected.

  The original vulnerability is here, for those preferring to skip CNN and go straight to it: http://sites.utexas.edu/iso/2015/09/15/android-5-lockscreen-...

• by ignoramous on 9/21/15, 8:29 AM

  Previously, any crash in the Keyguard (which used to reside in the same process boundary as the system_server) would have taken down the OS, and a (soft) reboot would have ensued. Now that the Keyguard runs in its own process, any crashes now only gets rid of the Keyguard window and exposes whatever window is behind it (usually a launcher window).

  I wonder if the actual fix is to have the "watchdog" ping the Keyguard's process for a heartbeat like it does so with other services within the system_server... That way, any flaw / crash in Keyguard and you essentially loose access to the OS too (until it come backs up from the reboot, and starts from a clean slate).

• by billpg on 9/21/15, 9:50 AM

  "But phones will remain vulnerable until they're updated with the latest software patch."

  So never then.

• by paws on 9/21/15, 8:58 AM

  OS X had a curiously similar screensaver vulnerability back in the early days. On 10.2.6 and earlier, attempting to submit a very long string (>65,537 characters if memory serves) into the screensaver password prompt would crash the screensaver and drop to the desktop.

  Making exploitation much easier was how around the same time Cocoa widgets got emacs-style bindings like ctrl-k, ctrl-y, ctrl-a. Through combining these shortcuts an attacker could quickly and exponentially increase the input string length.

  I never saw it documented online but I remember applying this same trick to logonwindow and OS X dropping into the so-called 'secret >console mode' -- full screen terminal, Linux-style.

  Background: https://www.securemac.com/macosx-screensaver-security.php

• by userbinator on 9/21/15, 10:42 AM

  I know you can just put a limit on it, but a string much less than 1MB in length entered into an edit field can crash a device with probably 1GB or more RAM? If there's a fixed-length buffer somewhere that's being overflowed, it's absurdly large for a password; and if there isn't and it's actually dynamically allocated, that's still pretty sad. I just can't help but ask "what were the people who designed and wrote this code thinking?"

  This bug just happens to have been brought up in a security context, but if other text edit fields elsewhere in the OS and apps will cause crashes too when fed long strings, that's not just a security issue.

• by jefffoster on 9/21/15, 10:05 AM

  Reminds me a little of JWZ's "on toolkits" (https://www.jwz.org/xscreensaver/toolkits.html).

  Writing lock screens is hard!

• by nisdec on 9/21/15, 8:44 AM

  Summary:

  1. Only affects stock Android 2. Only works with password protection (PIN, pattern = OK) 3. Already patched

• by jkrippy on 9/21/15, 12:31 PM

  I wonder if my kids found something similar to this on their Kindle Fire Kid edition. I have parental controls enabled but sometimes the tablet is still running after the predefined cut off time. I remember seeing one time that the PIN entry was popped up with a really long string of numbers in it. They are very very young and wouldn't be able to Google something like this so it was trial and error if they found it.

• by 2III7 on 9/21/15, 8:38 AM

  Not working on my S6. Can't paste nothing on password entry dialog.

• by mahouse on 9/21/15, 9:27 AM

  I seriously would like to know why did not they implement a limit of characters on that field.

• by PythonicAlpha on 9/21/15, 10:11 AM

  I can't understand in the first place, why copy & paste is active on a password screen that should lock the whole device at all!

  Of course, deactivating copy&paste would not be a valid solution for this, but the paste feature also could potentially leak user data to unauthorized persons. The copy feature could by accident reveal the password at places where they do not belong.

• by hawleyal on 9/21/15, 2:36 PM

  If you have physical access to the device, aren't all bets off anyways?

• by snowy on 9/21/15, 9:59 AM

  I have a galaxy S6 running android 5.1.1 with device encryption.

  The lock screen only accepts a password of 16 digits long.

  So.... Only some devices effected?

  EDIT:

  On further research its fixed on 5.1.1.

  Kind of a stupid fix? Just limiting the size on the input password field?

  Also I notice that you can no longer copy paste from the emergency call screen.

• by ccvannorman on 9/21/15, 1:23 PM

  facepalm

  The year is 2015. The basic security of basic devices remains more fucked than ever.

• by dsmithatx on 9/21/15, 12:48 PM

  I tried this on my phone last week when I read the article. One I can't cut/paste on my Note 4 Lollipop (At the emergency password screen). Two if you even try to cut/paste or take longer than a second to the phone locks and you have to start over on the password.

  Maybe it's because I use the finger print reader and password is for emergency. On my phone this hack seems virtually impossible after 10 minutes of trying really hard to get it to work.

• by sharmadwivid on 9/21/15, 7:51 AM

  Not working with my cell phone