
To hack an Android phone, just type in a really long password - chetangole
http://money.cnn.com/2015/09/16/technology/android-hack/index.html
======
mehrdada
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.

~~~
mtgx
Jesus, why do Android engineers keep getting security so wrong so often? And
they even bragged so much about how L is (finally) getting storage encryption
by default, which they promptly killed after the Nexus 6 launch (because
apparently they are stupid and launched the device without hardware
accelerated encryption, even though the chip supported...ugh).

We still haven't heard anything about it being re-enabled in Android M again
(or ever). Also, I remember reading about Android <4.4 (optional) storage
crypto being seriously broken as well.

It's unfortunate because many people probably _still_ believe they are getting
default storage encryption. Heck, all the _new_ stories on encryption and the
FBI still (falsely) mention how Android is encrypting the storage by default.
It reminds of media sites saying Skype is P2P and secure against eavesdropping
years after Microsoft announced it changed its infrastructure to a centralized
wiretap-friendly model, just like everyone else.

The gap between iOS and Android in terms of security (and privacy, too) seems
to only be increasing every year. If they keep this up I may finally switch to
an iPhone after years of being an Android-only user.

[https://medium.com/@FredericJacobs/apple-ios-9-security-
priv...](https://medium.com/@FredericJacobs/apple-ios-9-security-privacy-
features-8d82d9da10eb)

And that's even without mentioning the horrible update problem that Android
has. I've just learned to live with that by installing custom ROMs after my
phone stops being supported a year into its life-cycle, which is obviously not
ideal in terms of security nor is it something I should _have_ to do to get
better security.

~~~
jerf
"Jesus, why do Android engineers keep getting security so wrong so often?"

Security is hard. Really profoundly hard, not just superficially hard.

And despite the fact that nominally I'd expect to get upvotes for stating what
you'd think would be the groupthink consensus, my observation is that in the
field, even engineers explicitly tasked with security still often think it's
really easy and they're really good at it, so there's no great need for them
to budget lots of time for it. This turns out poorly. I do not toss this
around lightly because it's become cliche to just fling it around without much
care, but there's a lot of real, no-foolin' Dunning-Kruger effect operative in
this area.

(Your test for Dunning-Kruger on this matter is: If you're told you need to
secure something and you're going to be personally responsible for its
security, do you A: Say "Oh, that's easy, I'll 'just'..." followed by pretty
much any series of words, or B: get the cold flop sweats, _regardless_ of how
easy it may superficially seem?)

~~~
ajross
> Security is hard. Really profoundly hard, not just superficially hard.

Indeed. There is an army of naked celebrities dancing around the internet
today because of an "iOS" hole that didn't even involve the device OS at all.

Picking on specific features to announce "Apple is more secure" is very much
missing the point.

That said, yeah: I'm not a big fan of Android's security architecture either,
though it has been improving rapidly.

~~~
jtriangle
> though it has been improving rapidly.

This is an important factor, and maybe the fatal flaw in android's carrier
relationships. Google is always very fast to push a fix out, but the carriers
always drag their feet in getting the fix to the actual devices.

~~~
ajross
It's really not. We're talking about security architecture here (which rolls
out only with OS releases) and not security bugs (which get rapid patches on
all but the most negligent of OEM devices).

Having a better security architecture works (to stretch the metaphor) like
immunization: past a certain adoption level you reach a "herd immunity" state
where the marginal benefit to an attacker of a specific flaw drops rapidly to
zero even though there are still "old" devices out there in the market in
small numbers.

Basically, the market refresh cycle is still at something like 18 months, so
even given that OEMs are slow new Android releases are reaching the public in
large numbers fairly promptly.

~~~
jtriangle
That is actually a great point, hardware refresh is such that updates get
performed regularly. Also, this exploit requires hardware access to the phone,
which is generally considered game over in any respect.

It would be beneficial if carriers could come up with updates faster however.
I've seen Verizon drag its feet on more than one occasion, especially with
phones that are a generation or two behind.

------
ngcazz
Only thing that comes in my mind...
[http://i.imgur.com/rG0p0b2.gif](http://i.imgur.com/rG0p0b2.gif)

~~~
UnoriginalGuy
Windows 9x was never secure, and I believe that screenshot was taken from
Windows 98 or 98SE (hard to tell which).

Arguably this is a bug in HP's printer driver. But the fact Microsoft exposed
printing to begin with was misguided.

I will say, even then, Microsoft intended for businesses and schools to
utilise Windows NT 4.0 for this type of scenario. Unfortunately for them 9x
become too popular for its own good, so people were buying machines with it
and then having it log into AD (which was never really secure scenario, NT is
designed for this, 9x wasn't).

~~~
petemc_
You could do similar in SBS2003.

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

~~~
Someone
Emergency call is one of the features that must work for a device to pass
certification (numbers: 911, 112, and, a third one I cannot remember). In that
sense, this is not an unimportant feature.

However, AFAIK, not being able to make regular calls without using a password
isn't part of certification testing.

~~~
subway
I think "0118 999 881 999 119 7253" was the third one you were looking for.

~~~
junto
Great reference:
[https://www.youtube.com/watch?v=ab8GtuPdrUQ](https://www.youtube.com/watch?v=ab8GtuPdrUQ)

------
tombrossman
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-...](http://sites.utexas.edu/iso/2015/09/15/android-5-lockscreen-
bypass/)

~~~
pilif
How ironic that this bug affects the only really secure locking method.
Neither the pattern nor the pin are really safe to protect a device as both
are easily snoopable.

~~~
Vexs
Imo the pattern lock is really secure if you make it hidden at lockscreen.

~~~
madeofpalk
Recently there was a report around the pattern lock being the least secure and
having the least amount of variation between passwords.

Edit: Unfortunately I can't find the specific study I was looking for, so I'll
have to add my own [citation needed]

~~~
gambiting
Well, internally the pattern password is literally stored as numbers, just
like the pin. So If you go top right to middle right then to middle, then to
bottom middle, your pattern will be saved as 3658. It's less secure than a
pin, because obviously with a pattern lock a 3 can only be followed by a 2,5
or 6, and no number can repeat, so it's easier to crack than a pin.

~~~
drzaiusapelord
My pattern left a trail on my screen pretty much telling you my password.
You'd have to guess on the direction a couple times, but you'd get it fairly
quickly. I think the pattern lock is really just a way to keep kids off your
phone. Greasy fingers on glass are way too telling.

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

~~~
quotemstr
NT has a neat feature for essential processes: you can tell the kernel, "if I
ever exit, for whatever reason, panic the system and reboot immediately".
There's little room for error with a system like that. It wouldn't be that
hard to implement this feature in Linux too.

(Of course, you need to have special privileges to mark your process as
critical.)

~~~
jschwartzi
In Linux, if PID 1 ever goes down the kernel panics. You could put a watchdog
in your PID 1 that will take it down if the timer isn't tickled for a certain
period of time.

~~~
andrewaylett
Systemd has a couple of nice features around this: init can open the hardware
watchdog and ping it as required, so if init ever stops then the machine will
reboot. At the same time, services can be set up to need to write to their own
watchdog. So if a service dies, either init will notice and take appropriate
action, or init will also have died and the hardware watchdog will reboot the
system.

Also -- and this has been useful to me on a laptop -- init will configure the
watchdog as a last-resort to kill the system when shutting down.

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

So never then.

~~~
kozukumi
This is the number one problem I have with Android. Once I buy an Android
phone I pretty much expect 6 months of updates. Maybe longer if it is a really
big bug. Sure some OEMs have made "promises" to provide 2 years of updates but
that updates don't come out all that quickly, often several months after it
hits the main AOSP line.

If you want an iOS like experience with Android you have to buy a Nexus phone
of which the Nexus 6 sucked balls due to its size.

I wish Google hadn't killed the Play Edition phones. I would love a choice of
phones running stock Android, maybe with a few extra, optional, apps from the
OEM similar to what Motorola does. A Galaxy S6 running stock Android with a
guarantee of update within 2 weeks of it hitting a Nexus would be my perfect
phone.

~~~
sergiosgc
Just select your brand based on their ability to update phones for a couple of
years past purchase. Nexus phones are kept up to date. Motorolla too. LG seems
to be on that track, but History will tell. Samsung also pledged to update for
two years.

~~~
ocdtrekkie
Or just don't buy phones with an OS that the OS developer can't actually
patch. Buying Android is buying poor security.

~~~
sergiosgc
That is false. As long as the OS is updated, it does not matter whether it is
the OS developer, or the equipment manufacturer, publishing the update.

I wonder, if Apple delegated OS update publishing onto third parties, if you'd
keep your position. The Jobs distortion field extends beyond the grave, it
seems.

------
paws
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](https://www.securemac.com/macosx-screensaver-security.php)

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

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

Writing lock screens is hard!

------
nisdec
Summary:

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

~~~
stouset
"Already patched" isn't really as meaningful on Android as it is on, e.g., iOS
where the average user can expect to (and frequently does) update their
operating system.

How many phones are still vulnerable to StageFright?

~~~
izacus
The bug appears only on stock devices which are commonly updated. OEMs provide
their own lock screens which aren't vulnerable.

So in this case "patched" is pretty meaningful.

~~~
Tinyyy
How do you know they aren't vulnerable ;)

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

~~~
userbinator
That's a good thing. It means your kids are natural hackers. :-)

~~~
jkrippy
I'm totally OK with this too! :D

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

~~~
masklinn
It was fixed in 5.1.1 build LMY48M
([http://sites.utexas.edu/iso/2015/09/15/android-5-lockscreen-...](http://sites.utexas.edu/iso/2015/09/15/android-5-lockscreen-
bypass/))

~~~
chx
It's interesting how most Nexus devices only have a LMY48M image
[https://developers.google.com/android/nexus/images?hl=en](https://developers.google.com/android/nexus/images?hl=en)
but the razorg skipped that and has LMY48P (which I flashed yesterday, phew!).
Also, the 2012 Nexus 7 is still stuck at LMY47V.

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

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

~~~
Dylan16807
The copy is occurring on the phone number input, not the password screen.

~~~
PythonicAlpha
I understood that.

When they activate paste, I guess copy is active to ... (but I don't own such
a phone)

~~~
Dylan16807
It's very common for password fields to accept paste but not copy. I don't see
why you would assume that.

~~~
PythonicAlpha
Ok, I don't see, why they should accept paste at all!

~~~
Dylan16807
Have you ever used a password manager? As a general rule they should
definitely accept paste.

~~~
PythonicAlpha
A password manager for a locked device? Does that make any sense?

I do not have an Android phone or a password manager, but I still do not get
the point here. The device is locked, so how do I access the password manager?

~~~
Dylan16807
_As a general rule_ password fields should accept paste. 99% of them are not
on locked devices.

When you said "they" I thought you were talking about password fields as a
whole, not this single field.

And even then, any OS could be run in a VM, so why not accept paste, it won't
hurt anyone.

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

~~~
lotyrin
Not theoretically, at least.

Even attackers that can read your RAM perfectly can be thwarted by encrypting
things and unloading the keys from memory.

~~~
ultramancool
Those attackers could instead install a hardware based touch screen logger or
write a similar attack in software and write it directly to your phone's
flash. It's more complicated, but it's still true, once someone has physical
access, all bets are off.

~~~
lotyrin
Yes, a device which has been accessed physically shouldn't be trusted anymore
(theoretically) but I was talking about the case of a booted device being
stolen by an attacker, not the case of one having been returned.

In practice, If you can detect intrusion and the device has a secure boot
system, wipe the device and issue it new keys, re-encrypt all data to the new
keys with some backup cold-stored keys.

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

~~~
mpnordland
I tried this on my HTC One and I found that I couldn't copy anything from the
emergency call screen either.

------
ccvannorman
__facepalm __

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

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

------
sharmadwivid
Not working with my cell phone

~~~
SixSigma
Perhaps your computer doesn't get overloaded

