Why can this command unlock my lock screen without password? (Security question)

Question

I work at an IT company, started here not so long ago. Many of us are using linux, and I have discovered a problem or security issue with Ubuntu. As it is now, locking the screen is of no use in case there would be a user-enabled process running a certain command: gnome-screensaver-command --lock or loginctl unlock-session

None of the commands require a password to reactivate my desktop, and I honestly consider this to be pretty unsafe (or at least removing the safety around having a lock screen after all). I had expected it to ask for password when trying to re-enter the desktop environment.

I noticed this behavior upon developing my own bluetooth-lock functionality, so if someone moves away from the pc the screen will lock. But I had not expected it to be so easy to unlock it.

Are there any previous discussions around this? I find it very weird it is supposed to be this way.

Solution 1

No, this is not a flaw in lock-screen security

What do you expect to happen if you were to do something similar yourself for valid reasons? Say, you are using a different computer and you ssh into your usual one and run the command remotely?

This is something that we actually do where I work, as we have odd screensaver issues and haven't figured out why - our issue blocks someone from legitimately unlocking the computer, so they cannot get back into it. They generally walk to the nearest computer, ssh to the one that is locked, and unlock it remotely, then walk back. So what you described actually happens at my work location all the time.

It is not a security flaw because your computer should do what you tell it to do, and to the computer your user account is you.

So this could be a limit to security, a case that the security measures do not cover, but not a flaw in existing security. That would be like saying normal fences have a flaw in that they don't stop things from climbing or flying over them - no, that's not a flaw, just a limit to their security, one which you can implement other measures for if it's a concern.

Real-world analogy

As a physical analogy, you are describing crimes where thieves steal your house key when you're not looking, take it somewhere to have a copy made, then put the original back before you notice... and you are suggesting that this is a security flaw with keys that can be solved by banning key-copy services. Not that this would ban key-copying, as it would ban only the public service... people would still copy keys, just like people would still sneak malware onto your computer if you walk away with it unlocked.

How to increase security

The Bluetooth proximity unlock you mention sounds excessive, but if this is truly a massive security issue for your place, then that is one of the better ways to go. You probably don't even need to develop this yourself, as there are probably products which do this.

To continue the analogy, the Bluetooth proximity thing would be like having an alarm that triggered if your house key was moved too far from you. That would require thieves to do their work behind your back with you nearby; still possible, but more difficult.

Some other security methods might involve training people to always lock their screens when leaving their desks, or even further having a policy which states that all computers must be locked if the user is not within sight of it.

That is actually a policy where I work. If I walk away from my desk even just around the corner for 60 seconds for a coffee (which is in ear-shot of my desk and I can peek around the corner at it), and if I forget to lock my computer while doing so I can get into trouble. It is part of our security policy, and people are reprimanded for it.

Another thing to do would be reduce auto-lock timeouts. If they are at 10 minutes now, put them at 1 minute or less. That can be annoyingly short when reading a page of text, but if it's a big enough security concern then people need to just deal with it.

Reducing auto-lock time will stop your stated scenario from occurring in the cases where someone happens to walk by a few minutes after you walk away and see you're gone and your computer is unlocked. The vulnerability will be available only to those people who are actively stalking you and are ready and waiting to pounce on your user account seconds after you walk away.

Take-away

100% security is impossible

No matter what you do, it will not be possible 100% to stop what you describe. Someone can subvert a computer even if its user is present. Someone could stop by while you're at your desk, supposedly just to talk to you.

Hey, is that the ABC file you have up? Can you scroll up so I can point something out to you.

[slips USB drive into computer while you're staring at monitor]

@Paŭlo Ebermann commented "Your attacker doesn't even type the command for the malware, his USB device can just pretend to be a keyboard too." Very true, thanks for making the point even better. Deleted extra unnecessary steps.

And that's assuming that you couldn't just get someone to run your malware themselves. "Hey Bob, can you try out my newest version of our software? I think I got the bug fixed." (Bob then runs the software he is developing with Tim, not knowing Tim put malware in that specific build of it, then Tim deletes it in 5 minutes)

That's all it takes, then your computer account is already 100% compromised, even while locked.

1. It is practically impossible to protect a user account from the actions taken by that user account, and

2. it is practically impossible to guarantee that the actions taken by that account are all exactly what the account's human owner desires.

To go back to the analogy...

I used the key example because of your specific lock-screen case, wherein the lock-screen is the key. But, as pointed out by commenter @David Z, the problem is actually worse. By analogy, the key theft is a minor concern as you already have people living in your house without you knowing it, and they are doing whatever they want all day while you are gone, even though your door is locked.

If you're fortunate they will leave a mess and you'll come back to a home that looks obviously ransacked. "What??? If I'm fortunate?" Yes, because the worst case is far worse. They could live in your house for years, always picking up after themselves, so that they can keep stealing from you and living in your home for years without you even noticing. Or even using your home as a hub for criminal activity, like drug sales or pawning stolen items.

That would be like your office's computers all having key-loggers, remote control software, constantly downloading all your company data, or even being consumed as part of a botnet such that those computers could actually be engaging in illegal activity every day without you even knowing. All while the door is still locked.

---

I just stumbled on this great XKCD joke and it reminded me of this answer, so I've added it. Notice the 5th "security vulnerability" from the bottom.

Solution 2

In both use-cases, these seem like secondary issues.

If somebody can run gnome-screensaver-command or loginctl as you, remotely, your home, your $PATH, essentially your whole computer —from the perspective of your security and privacy— is compromised.

If somebody just rocks up at your computer, they can't just run this stuff.

Solution 3

I am reminded of this U&L question about sudo granting root access. Yes, a command running under your user account is able to unlock your computer. This is because, under Linux's security model, any command running under your user account is you.

There is effectively no difference between a command issued by a program that you launched and a command that you issue, whether through the GUI or a terminal. If you are running program that unlocks your screen automatically, your screen is unlocked, because there is no distinction between you clicking a button triggering the program and the program running some other way. If you run a program written by a malicious attacker, then your user account is totally and irrevocably compromised. A service written by this attacker could unlock your computer, yes, but the service could also allow remote access to your session already, or do anything the attacker wants.

So yes, you could possibly configure your system to only allow a program that does prompt for your password to unlock your system. But if you have to do that, if you're trying to prevent a malicious program, running under your user account, from compromising your user account, then you have already lost.

TL;DR: The program can do that because it's already logged in as you. You can do that because it's your account, just like how you can rm -rf ~. UNIX-like systems have traditionally not been in the business of preventing you from shooting yourself in the foot. If you can't keep control of what runs under your account, you've lost control of your account already.

Solution 4

Other answers focus on attackers, where it absolutely isn't a security flaw, because you need to already have access to run this command.

However, there is another concern here. In a company, IT security needs to be able to secure computers without the user being able to change security settings. In the scenario of an employee who is annoyed by locked screens, the employee can schedule a chron job to unlock the screen on a regular basis, effectively keeping the computer unlocked entirely. This weakens the security of a device/account significantly. So yes, it is a problem. Such a system is not adequate in terms of company IT security.

View more solutions

Comments

[Tiziano S.]

Solid point, I thought about the same thing. But it has other issues - planting a service on a computer left running unlocked for lets say 5 minutes (grabbing a coffe - this is really common within the company and we're working on implenemting a policy where people locks their computers). When the day is over I go home, leave my laptop here, and they can enter and log in - potentially do whatever they want then when they have time, and don't have to worry for me / the user coming back anytime soon.

[Oli]

You're still allowing the attacker a window. Let's be straight here, if you leave a driven attacker alone with your unlocked and/or unencrypted computer for longer than ~30 seconds, they now "own" that user account. Any commands it runs can be subverted, full remote control can be established. It doesn't matter that they can unlock the screen. Stopping that initial window is the goal.

[Tiziano S.]

I do 100% agree with you, no doubt. My question is more about, should it be so easy to bypass the lockscreen with only a command from the user side? Can't installed programs have this opportunity? And why are there no password required after running either of the commands?

[muru]

@Denny that would just be security theatre. Inconvenience masquerading as security.

[user1686]

@Denny: Installed programs don't need to bypass this. They already run inside the walls, so to speak. The screen lock functionality is like those door locks with a keyhole outside but a knob inside – it's there to protect the computer from outsiders, not from itself.

[Paŭlo Ebermann]

Your attacker doesn't even type the command for the malware, his USB device can just pretend to be a keyboard too.

[Aaron]

@PaŭloEbermann Very true. Edited accordingly and credited you. Thanks.

[Nonny Moose]

They can if you're like me and you accidentally leave ttys logged-in.

[Peter Cordes]

@PaŭloEbermann: Is momentary physical access dangerous? has an answer with a real-world account of a USB attack to install a back-door for corporate espionage, using exactly that

[Peter Cordes]

@Denny: Is momentary physical access dangerous? on security.SE has an answer with a real-world story of plugging in a USB for a few seconds in an unlocked desktop to install a back-door for corporate espionage. If the machine is connected to a network, momentary physical access to an unlocked system means that future physical access is irrelevant.

[jkinter]

I think a better physical analogy is an intruder hiding in your house. You probably wouldn't complain about the fact that someone who is already inside your house (i.e. a program running under your account) can mess with your stuff without needing a key (password).

[Tiziano S.]

Very nicely written. I start to get the point of how it works, and that it's already breached in case someone would have access. I am not denying that - and I understand the way of thinking. Perhaps it isn't as bad. I marked this as my final answer since it covers it all nicely, and would be a nice read for future curious minds.

[vidarlo]

Luckily most sys admins are smart enough to recognize that once an attacker can run stuff as local users, they've pretty much lost.

[Mast]

It all boils down to no longer being secured the moment an attacker has physical access. The lock screen is a deterrent, but won't stop a determined attacker.

[timuzhti]

This is a good point, though edit access to crontab could be locked down to administrators in a corporate environment. Using access controls or some other method (e.g. noexec mount option) to prevent execution of unauthorized binaries would probably also be desirable. In any case, +1 for an important factor that should be taken into account.

[stefan]

@Alpha3031 the measures you suggest are valid mitigations, but they are just that: the command will still be executable in one way or the other, as the underlying problem is not fixed.

[Aaron]

@DavidZ Added that analogy update to the end. Thank you.

[timuzhti]

The command would be executable by a logged in user. If a locking policy and a executable policy is properly implemented then there is no issue, since the command isn't executable from a locked screen. The user has to log in to unlock the screen.

[Tiziano S.]

Nice picture from XKCD haha, 11/10