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.
I remember an idea, but I forgot where or with whom I discussed it before, so sorry no link or reference. Locking a phone is not so different in my opinion than locking a desktop, it just let some shortcut for “guest” application on the lock screen directly.
The only difference with the switch to a new user that we have on a desktop, is that a “guest” switch is only temporary and any file created will be imported back in the profile of the main user. Example in the camera application, while you switch in it from the lock screen, you see no picture, as you take them, they start to appear. Once you are done and go back to the lock screen, they are moved to the main account and if you come back to the camera application from the lock screen, it will be empty again.
From a security point of view, if you can create a guest account home directory on the fly, track the change in a few designed directory and report them back at the end of a session, that’s exactly what you want.
Maybe, it was with some people from systemd while talking about systemd user session. Don’t know, I forgot !
That’s a neat idea with the guest session. Not sure how it would work for incoming phone calls, but situations like emergency calls should work nicely.
Well, for phone calls you can put them on ‘Hold’.
Alternatively with incoming phone calls you only need the “accept/decline” + talking functionality. You do not need to be able to call arbitrary numbers, copy phone numbers, manipulate contact entries etc. etc.
Thus, the phone functionality really isn’t a security vulnerability per se: you just need to have a ‘passive’ version of the call UI as well as a fully ‘active’ one.
ah but is there a difference? If we add a “dumb ui” who ensures that it doesn’t have bugs allowing to switch to the full ui?
You do. There’s varying degrees of just how ‘dumb’ is your UI, and I’d say that for a lock screen the UI can be really, really, really dumb. It could be two buttons that say “Accept” and “Decline” respectively.
That could be implemented in the lockscreen natively or in a library that the full fat call UI happens to depend on, also: but you make sure that *this* bit of code is so dumb it can’t even privilege escalate.
Note: there is no requirement that people who want to install 3rd party call UI stacks have theirs integrate automatically with your lockscreen. There is no requirement that people who install 3rd party lockscreens have theirs automatically pick up the Accept/Decline call functionality. There is no requirement to be able to make *arbitrary* outgoing phone calls, merely whitelisted ones (emergency number).
If people really really want to call into a robo-automated callcenter from hell with 7 level menus, taking the time to unlock their phone is no great burden compared to the ‘hold’ music they’ll be forced to endure anyway.
You probably also want to display the name of the caller, if they are in your contacts, which means this would need access to your contacts as well
And write to the call log.
Incoming phone call needs at least read access to your phone book (you want to know who is calling), and write access to the “incoming calls” list.
No you don’t. For an incoming call you make sure that all the relevant data is prefetched and passed as part of the signal. Within the context of Linux, such a thing is fairly easy to do through fd passing & sealed fds.
Secondly ‘accepting’ is again done not directly but by an intermediary which also handles the sensitive task of setting up pulseaudio streams.
Essentially the lock screen only ever sees ‘token’ information, and if it wants to act on that info it can do so but only certain predefined whitelisted actions by passing that token back to the backing OS level service method call.
So all fs access can be eliminated from the lockscreen. The lockscreen can’t even turn on the mic to eavesdrop on you, because it doesn’t have a valid token yet. It doesn’t even control the audio streams which the OS level service can yank at any point it cares to (when the call is actually disconnected) because, again, it only has the tokens and only the one OS level service that will respond to those tokens.
As I said in my blog post: yes phone calls can be solved. But it’s only part of the problem scope. People are not satisfied with that: they expect more from their phone.
So as you wrote: time to take a step back and survey what the whitelist for ‘things people should be/need to be able to do from a lockscreen’.
I don’t think this will turn out to be all that different from the desktop/laptop or tablet case. I think it’s not the form factor that determines this per se, it is the availability of certain hardware that does.
I mean, if you have a SIM card in your laptop then if you receive a call to that SIM you want to be able to deal with that from the lockscreen regardless. Similarly if having a camera functionality on the lockscreen of a phone is a good idea, then why not for a tablet?
Do you answer skype calls from your desktop’s lockscreen? No, you don’t and it would not be added because it’s a stupid idea. Why do I say that? Because use case: when a notebook or desktop is locked it normally means you are not around, you cannot answer the call because you are e.g. in the bathroom. For a phone that’s different. Most of the times when your phone rings it will be locked. It’s the rule not the exception.
Use cases are different, requirements are different.
That’s true, as far as it goes. I definitely don’t want to do a video call from the lockscreen. But equally with the phone in a docking station much the opposite applies: the lockscreen would be a sign of me being away and calls shouldn’t be accepted either. 😉
You could say you want to deal with the common case and ignore the rare/edge cases (notwithstanding the whole convergence thing), but I would say that the function of the lockscreen, its purpose and reason for being, is the same across the devices: to keep people out.
I suppose the difference is that I would really like to be able to use the phone and tablet as a replacement for the laptop using suitable peripherals. That’s the sort of thing that ought to be quite doable/possible with quad/octo core processors and 2-4G of RAM and a high bandwidth bus.
Interesting thoughts. Yes from a convergence point of view a shared lockscreen makes sense. Though one could also say that on a “phone acts as desktop” case the lockscreen behaves like a desktop. After all to react to the phone you would pull out the connected wires anyway in which case it would immediately morph back into the phone with the phone lockscreen allowing to answer the phone call.
That needs more though 🙂
I think, guest account and read only permissions + synchronizing files call logs etc is good approach. We can also disable USB when there isn’t anything attached to it when lock screen is activated remaining it in charge only state. I don’t really see any reasonable care when user must need attach something to locked device. Lock screen applications should also be limited by kernel to access really needed functionality (maybe some sort of sandbox?)
disabling usb might not be as easy as it sounds. The idea is in general good, but usb needs to react on something attached otherwise it would not be possible to charge.
Similarly for the camera part you could mandate that the user supplies the password at the end of taking a picture or else the photo/video will be deleted from the proposed ‘guest’ account. When the password entered correctly the phone is unlocked and the data is transferred into the main account.
That way you even get around the DOS/prank of random people shooting as much photos/videos as they can to fill up the disk and annoy the owners of the phone.
While I mostly agree with your assessment, I still see a few use-cases where someone else physically “owns” your device without stealing / taking it away from you (forever).
E.g.
– You leave your phone at the wardrobe, during theater, opera, etc.
– You have to hand out your phone during a visit of a plant, factory, construction site, etc.
– You are searched / held of by airport security, border control, police, etc.
Of course one can argue if there are malicious people in these scenarios, they will surely have an USB-cable, but still I think these scenarios are worth to be considered.
for 1 and 2 I would require a locker or not hand it out. For 3: sorry that means dealing with the power of intelligence services.
Very interesting post, but I have to disagree with your conclusion, because you don’t really address the case of an encrypted hard drive / storage.
If I keep my hard drive encrypted, the only way to access it is when the key resides in the memory, that is, when the device is running and the user is logged in. So if I manage to steal an encrypted device with a breakable lock screen, it is easy to get all the data on it. Stealing a currently running desktop computer on the other hand is rather unusual.
So for most users[*], a secure lock screen on the phone may be even _more_ important (and not less) than on a desktop computer, which is usually being turned off when it is not needed and much harder to steal.
Anyways, thanks again for your blog post and I hope I didn’t misunderstand you or missed an important point, but I’m looking forward to your thoughts on this!
[*] “most” may be a little exaggerated here, but as newer Android versions make device encryption really easy and Google even promised to make it the default in the future, I think it that there might come a time where “most” users really have encrypted phones.
No, actually I didn’t miss the point. I am quite aware of hard-disk encryption and I gave the answer to it: lock screens don’t protect against screw drivers. If I get access to your running system with a screw driver I’m able to extract your hard disk encryption password (in worst case for me as attacker: cold boot attack).
Okay, but when we speak of cold boot attacks, we usually deal with players like intelligence services which may be out of scope here anyways 😉
But the common thief is far more likely to follow a guide on the internet that tells him to copy/paste some text into the emergency calling app in order to unlock the phone, as it appears to be the case in the android vulnerability, than to actually use any screwdrivers…
cold boot intelligence service only? During my studies I had a lecture on computer forensics, we had a guest talk from a LKA guy, he told us it’s part of the standard tools they use.
Protecting against thief: yes they might be able to follow such an instruction, but they will also be able to follow the “how to attach usb and trigger remote vulnerability”. That’s the point where you have lost: the device is owned by the attacker.
Hm, I have to admit that I don’t have an good assessment on how hard it really is to perform a cold boot attack and who is able to do it (from the few papers I read about the topic I gained the impression that it remained a theoretical vulnerability for a long time, so I’m rather surprised to hear that the LKA is using it as part of their standard toolkit).
Nevertheless I think one shouldn’t make the lock screen less secure just because other components of the system may be vulnerable as well.
But I also understand the problems you pointed out in your blog post and it’ll be interesting to see suggestions on how to tackle these issues.
From the foto app you can go to the gallery app and perhaps even further. I’d leave it to the user what he or she allows and what not. By default the phone app and notifications are allowed to drill holes but anything else should be done intentionally.
You think a user can do an educated decision about that including the risk that this might break the lock screen?
Hello there,
I agree that there should be a stripped down version of the phone UI.
It should have the opportunity “emergency numbers” to call but not to use USSD codes. Longer numbers than 4 characters are not necessary.
If the phone is locked, it should not be possible to use its USB data transfer function.
Generally it should be give a log service, provide for fault / Unlook fails and so on.
I would also by default take a photo shoot if anyone enters the 4x Lockpin wrong.
The problem with external apps in the Lockscreen is that you do not know what kind it is. And if there exists a vulnerability.
So I have only one idea in which direction the problem goes.
I thinking you could embed a virtual screen which is in a sandbox.
And in general the system to toughen the the lockscreen not break away.
But that does not solve the problem completely. Because you still do not know how the “Lockscreen app” (Skype, for example) in an attack with an exploit responding. And so, for example, higher right procured.
An own IPC system is I do not think the whiteness recent statements.
Greetings and a nice evening
Jonas S.
I get the accepting phone calls and the emergency calls requirement, but taking a picture? That’s a convenience feature I that I, as a user, would not want to compromise security for.
I mean yes, sometimes you want to snap a photo really quickly, but it’s not like unlocking your phone takes 10 seconds.
Just because Google added this doesn’t mean it makes sense. That said, if we really want to offer this, I agree with Heiko that it should be optional (and disabled by default). We could add an option to allow taking photos while the phone is locked, adding a “This can compromise your phone’s security, use at your own risk!” warning/disclaimer.
Android also has an option to choose whether one wants to show all notifications, only non-privacy-sensitive ones or no notifications on the lock screen. Yes, this decision needs less technical expertise than the lockscreen one, but off by default + warning should work for our case.
Basically just giving up on a phone lock screen’s security because it can’t be perfect isn’t the way to go imho.