I’m surprised that unlocking the phone is as easy as calling .dismiss() on a UI element. The fix of calling dismiss(enum) is still flimsy.
I’d expect locking to go deep into the OS. Make the kernel and window manager unable to run normally until they’re explicitly told to allow normal operation by auth-handling code, not the GUI stack. Perhaps even keep the disk locked and make unlock actually impossible without a decryption key derived from the pin or provided by fingerprint scanner, so no matter how buggy the UI code is, it can’t fail open.
But the whole phone security is just a screen saver!?
They may have fixed the race condition, the post doesn’t specify. In any case, having an enum is a good idea. Having .dismiss() blast away whatever security screen is on top of the stack clearly opens the door for bugs. It would be better to have each security screen have something like a session ID (or unique object handle) that can be dismissed explicitly, but targeting the type is certainly better than nothing.
But I know it, and I know I can log in as me and pkill i3lock and have my computer unlocked. Phone users don’t know this, and it should be more secure in an integrated environment like that.
Right, this just suggests that the entire security model of the system is mediocre at best. Like. as a trivial example, the user filesystem shouldn’t even be mounted without the biometric/PIN explicitly unlocking it. Instead it seems like the entire system is up and running before any authentication has occurred? Or something?
Developers have always known how to make these secure, usually involving some black magic where a microcode block or a set of machine instructions is the output from the unlocking sequence. On the down side, it is black magic and so some of your developers will not understand making calls into data returned.
Im not familiar with how experiences reporting security flaws usually go but this seems like a shockingly mild response from the google team given how severe a security flaw this was? $70,000 seems about right but I’m very surprised this was allowed to exist in Android for as long as it was?
Every step here looks and smells like a ‘oopsie’ backdoor. Plausibly deniable, high contextual worth for LEO, low risk for abuse or discovery outside of it.
The JWZ complaint always struck me as a bit odd because X11 has a mechanism called reparenting that allows one process to render things that then appear in another window. It would be easy to allow the lock screens to use a rich toolkit by running them in a child processes and reparenting their window into the XScreenSaver one, and just restarting them if they crash.
I’m a little puzzled. I thought the storage was actually encrypted on these things, and the existence of this bug seems to strongly suggest otherwise unless I’ve severely misunderstood. If swapping out an attacker controlled SIM can get you access to the device storage, it’s not encrypted, right? Is everything here a lie?
After accepting my finger, it got stuck on a weird “Pixel is starting…” message, and stayed there until I rebooted it again.
After rebooting the phone, putting in the incorrect PIN 3 times, entering the PUK, and choosing a new PIN, I got to the same “Pixel is starting…” state.
I thought the same thing until I saw these snippets. I believe the “Pixel is starting…” screen is it decrypting the phone using your pin (and failing in this case).
To my knowledge an Android phone is encrypted (if you have encryption enabled) when shut off. On boot, you decrypt it using a pin or password.
After the decryption after boot the lock screen is just a simple lock screen. It prevents somebody from accessing your data through the GUI, but the decryption key is loaded somewhere and a dedicated attacker might be able to get the data off a running phone.
There is also a small difference between the two lock screens. The first lock screen (which decrypts the device) has a small additional message telling you to unlock the phone to use all features (translated it from my language, probably other words on native English devices). The lock screens afterwards do not show this message.
I’m really bad at mobile phones though, so my understanding might be wrong. That’s how I understood it when I researched android device encryption.
To my knowledge an Android phone is encrypted (if you have encryption enabled) when shut off. On boot, you decrypt it using a pin or password.
For a while now android uses file-based encryption and not full-disk encryption. This means that on boot there is no longer a point where you need to type the password to continue booting. Android’s file-based encryption allows the phone to boot all the way to the lockscreen. However at this point user data is still all encrypted.
After the user types their pin correctly (the first time after boot) user data is decrypted.
And yes you’d be correct that after this point the user data is decrypted and the lockscreen now just acts as a lockscreen.
but the decryption key is loaded somewhere and a dedicated attacker might be able to get the data off a running phone.
That’s not entirely correct, at least not for modern phones with dedicated security chips, like the Pixel’s Titan M. The decryption key is ‘stored’ in the Titan M - its very much protected in there. I say ‘stored’ in quotes because its technically a lot more complicated than that (Key Encryption Keys, Weaver tokens, etc).
That’s how I first interpreted this too, but in the demo video you can see that they never turn the phone off.
It’s still a pretty useful bug. If someone steals/seizes your phone you don’t have time to turn it off, and you probably don’t carry it around powered off.
To be honest I don’t really like finding behaviors like this when I am not looking for them explicitly, because when this happens, I am prone to feeling obsessively responsible to investigate.
So the lesson from this is that if you report a security bug and it looks like getting closed as duplicate, negotiate a bounty regardless. It’d still have value if you were going to sell it on the dark web if they can’t get a fix out in no time.
Can one claim that the three finger salute holds up better against XScreensaver and this bug? Does the fact that Windows is natively graphical play to its advantage?
I don’t know if it holds up better, but the screensaver is on a separate desktop than the default desktop is on a separate desktop than the login screen. These desktops are different than X11 style virtual desktops, and are a sort of security boundary. The screensaver simply crashing will not lead to the desktop being switched IIUC, and calling SwitchDesktop is guarded against from those secured desktops.
I’m surprised that unlocking the phone is as easy as calling
.dismiss()on a UI element. The fix of callingdismiss(enum)is still flimsy.I’d expect locking to go deep into the OS. Make the kernel and window manager unable to run normally until they’re explicitly told to allow normal operation by auth-handling code, not the GUI stack. Perhaps even keep the disk locked and make unlock actually impossible without a decryption key derived from the pin or provided by fingerprint scanner, so no matter how buggy the UI code is, it can’t fail open.
But the whole phone security is just a screen saver!?
Yeah, after reading I too find it kind of obscene the “fix” is an enum instead of fixing the underlying race condition
They may have fixed the race condition, the post doesn’t specify. In any case, having an enum is a good idea. Having
.dismiss()blast away whatever security screen is on top of the stack clearly opens the door for bugs. It would be better to have each security screen have something like a session ID (or unique object handle) that can be dismissed explicitly, but targeting the type is certainly better than nothing.It’s almost like it’s just pretending to be locked.
I wish we could see the iOS source to compare the two and try to get the best possible solution.
This seems informative: https://securephones.io/main.html#Ch1.S1
That’s how it works on my laptop.
But I know it, and I know I can log in as me and pkill i3lock and have my computer unlocked. Phone users don’t know this, and it should be more secure in an integrated environment like that.
I posted a comment linking to a JWZ blog rant about these kinds of bugs in screen lockers, and then discovered someone else had already posted it as a top-level comment.
Right, this just suggests that the entire security model of the system is mediocre at best. Like. as a trivial example, the user filesystem shouldn’t even be mounted without the biometric/PIN explicitly unlocking it. Instead it seems like the entire system is up and running before any authentication has occurred? Or something?
Developers have always known how to make these secure, usually involving some black magic where a microcode block or a set of machine instructions is the output from the unlocking sequence. On the down side, it is black magic and so some of your developers will not understand making calls into data returned.
Im not familiar with how experiences reporting security flaws usually go but this seems like a shockingly mild response from the google team given how severe a security flaw this was? $70,000 seems about right but I’m very surprised this was allowed to exist in Android for as long as it was?
Every step here looks and smells like a ‘oopsie’ backdoor. Plausibly deniable, high contextual worth for LEO, low risk for abuse or discovery outside of it.
That’s a great point. That leads me to wonder if the “fix” similarly contains a new, even more obscure path to bypass the lock screen.
This reminds me of the many security problems that allow bypassing various Linux lock screens that JWZ has extensively documented.
The JWZ complaint always struck me as a bit odd because X11 has a mechanism called reparenting that allows one process to render things that then appear in another window. It would be easy to allow the lock screens to use a rich toolkit by running them in a child processes and reparenting their window into the XScreenSaver one, and just restarting them if they crash.
This is what
xsecurelockdoes.I’m a little puzzled. I thought the storage was actually encrypted on these things, and the existence of this bug seems to strongly suggest otherwise unless I’ve severely misunderstood. If swapping out an attacker controlled SIM can get you access to the device storage, it’s not encrypted, right? Is everything here a lie?
I thought the same thing until I saw these snippets. I believe the “Pixel is starting…” screen is it decrypting the phone using your pin (and failing in this case).
To my knowledge an Android phone is encrypted (if you have encryption enabled) when shut off. On boot, you decrypt it using a pin or password.
After the decryption after boot the lock screen is just a simple lock screen. It prevents somebody from accessing your data through the GUI, but the decryption key is loaded somewhere and a dedicated attacker might be able to get the data off a running phone.
There is also a small difference between the two lock screens. The first lock screen (which decrypts the device) has a small additional message telling you to unlock the phone to use all features (translated it from my language, probably other words on native English devices). The lock screens afterwards do not show this message.
I’m really bad at mobile phones though, so my understanding might be wrong. That’s how I understood it when I researched android device encryption.
For a while now android uses file-based encryption and not full-disk encryption. This means that on boot there is no longer a point where you need to type the password to continue booting. Android’s file-based encryption allows the phone to boot all the way to the lockscreen. However at this point user data is still all encrypted.
After the user types their pin correctly (the first time after boot) user data is decrypted.
And yes you’d be correct that after this point the user data is decrypted and the lockscreen now just acts as a lockscreen.
That’s not entirely correct, at least not for modern phones with dedicated security chips, like the Pixel’s Titan M. The decryption key is ‘stored’ in the Titan M - its very much protected in there. I say ‘stored’ in quotes because its technically a lot more complicated than that (Key Encryption Keys, Weaver tokens, etc).
The key is stored, there but the data is not. Which is what the commenter above said that the attacker could get.
Oh, I see.
So, is the thought here that inserting the new SIM and resetting its PIN then resulting in a “unlock encrypted user volume” functionality?
I honestly have no idea. In fact I’m surprised doing anything with the SIM affects the encryption system like this.
I was assuming the physical SIM swap involved a reboot. Maybe that was too generous an assumption.
The video clearly shows doing the SIM swap whilst powered on.
I didn’t doubt that. But I thought swapping it would reboot from a cold state, not hold any decryption keys in memory.
That’s how I first interpreted this too, but in the demo video you can see that they never turn the phone off.
It’s still a pretty useful bug. If someone steals/seizes your phone you don’t have time to turn it off, and you probably don’t carry it around powered off.
I felt this in my bones. 😩
So the lesson from this is that if you report a security bug and it looks like getting closed as duplicate, negotiate a bounty regardless. It’d still have value if you were going to sell it on the dark web if they can’t get a fix out in no time.
Can one claim that the three finger salute holds up better against XScreensaver and this bug? Does the fact that Windows is natively graphical play to its advantage?
I don’t know if it holds up better, but the screensaver is on a separate desktop than the default desktop is on a separate desktop than the login screen. These desktops are different than X11 style virtual desktops, and are a sort of security boundary. The screensaver simply crashing will not lead to the desktop being switched IIUC, and calling SwitchDesktop is guarded against from those secured desktops.
This seems similar to having the lock screen be on a different VT, say directly in the login manager – I think gdm should work like that these days…