These days we can read a lot about a lock screen vulnerability in the Android system. Given that I have spent quite some thought on how we can use Plasma’s lock screen on our phone system I take the incident as an opportunity to share some thoughts about the topic. The tldr is “much ado about nothing”.
In Plasma we have an in my opinion rather secure infrastructure for the lock screen. Of course it suffers from the general problems of X11, but once it’s ported to Wayland it will be truly secure (till the first exploit is found). Given that I would like to use our lock screen architecture also on the phone. It’s secure by not letting anyone in even if the lock screen crashes (one of the problems hit in the Android exploit), by ensuring nothing else is rendered and no input is passed to any other application. So awesome! It will be secure!
But on second look we notice that the requirements on phone and desktop are different. On a phone we need to allow a few exceptions:
- Accept phone calls even if screen is locked
- Interact with notifications (e.g. alarm clock)
- Allow emergency phone calls
The last item is also an important part of the puzzle for the Android exploit. These exceptions directly conflict with the requirements for our lock screen on the desktop. To quote:
Blocking input devices, so that an attacker cannot interact with the running session
It allows interacting with the running session (even more with the hardware) and it doesn’t block input devices any more.
I have over the last months spent quite some time thinking about how we can combine these requirements without compromising the security and so far I haven’t come to a sufficient solution. All I see is that if we allow applications (e.g. phone app) to bypass the lock screen, we in truth add a hole into the architecture and if there is a hole you can get through it. There will be ways to bypass the security then. No point in fooling ourselves. A phone app is not designed for the secure requirements of a lock screen.
Now phone calls are not all we need to care about on a lock screen – this could be solved by e.g. integrating the functionality into the greeter app. Users might want to take photos without having to unlock the screen (another piece of the Android exploit). It’s from a security perspective a questionable feature, but I can understand why it got added. Now this feature directly adds a huge hole into it: it writes to the file system. I can easily imagine ways to bypass the lock screen from a camera app, get to the file system, etc.
At this point we need to take a step back and think about what we want to achieve with a lock screen. On the desktop it’s clear: if there is a keyboard somewhere you should not be able to penetrate the session even if you have hours to try. But on a phone? Does this requirement hold? If I have the chance to unattended attack the lock screen of a phone, it means I own it. For desktop hardware we can say that the lock screen doesn’t protect against screw drivers. This also holds for phones. If one has enough time, it’s unlikely that one can keep the attacker out and the lock screen is most likely not the weakest link in the chain. Phones have things like finger print readers (easy to break), various easy to reverse construct passphrase systems, simple passwords, etc. So the lock screen itself is relatively easy to bypass and then we have not even looked at all the things one can do when attaching a usb cable…
Given that the requirements for phone security might be different? Maybe it’s not about blocking input devices, preventing anyone to get in? Maybe the aim is only to hold of people having access to it when unattended for a few moments?
If that’s the aim our lock screen architecture of the desktop might even be over done, adding holes to it would be wrong and we shouldn’t share the code? It also means that the Android vulnerability doesn’t matter. The exploit is a complicated process needing quite some time. The lock screen prevents access for uneducated people and also for those having just a few moments of unattended access. It only breaks in situation where it might not matter: when you already physically own it.