2

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.

  • 1
    The security issue seems unclear. Are you are saying that loginctl allows you to unlock other folk's locked sessions when you lack admin permissions? – user535733 Aug 3 '18 at 12:26
  • @user535733 I don't think that's the case though. At least as far as documentation goes, you can only unlock your own sessions. gnome-screensaver-command would need authenticated access to your screen too. – Oli Aug 3 '18 at 12:27
  • @user535733 no, this would be more of a case where someone is able to plant a service on your machine if you are away for a few mins, leave the pc unlocked. This gives them access to my PC for example when i leave work later, and the computer is only "locked". – Denny Aug 3 '18 at 12:30
  • 34
    As the legendary Raymond Chen says, this rather involves being on the other side of the airtight hatchway. If the attacker can run programs in the name of your user account they have already compromised your account. – AlexP Aug 3 '18 at 13:24
  • 1
    @Denny If they are able to insert such a program why not simply install an SSH server that listens to a strange port... that way you have remote access to the machine whether the other guy is at the PC or not... – Bakuriu Aug 3 '18 at 18:39
16

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.

CVE-2018-?????: It turns out Bruce Schneier is just two mischevious kids in a trenchcoat.

  • 1
    Your attacker doesn't even type the command for the malware, his USB device can just pretend to be a keyboard too. – Paŭlo Ebermann Aug 3 '18 at 20:12
  • @PaŭloEbermann Very true. Edited accordingly and credited you. Thanks. – Aaron Aug 3 '18 at 20:55
  • @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 Aug 3 '18 at 23:24
  • 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). – David Z Aug 4 '18 at 7:24
  • 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. – Denny Aug 4 '18 at 7:49
43

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.

  • 32
    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. – Oli Aug 3 '18 at 12:39
  • 1
    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? – Denny Aug 3 '18 at 13:26
  • 9
    @Denny that would just be security theatre. Inconvenience masquerading as security. – muru Aug 3 '18 at 13:37
  • 12
    @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. – grawity Aug 3 '18 at 16:03
  • 3
    @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. – Peter Cordes Aug 3 '18 at 23:28
14

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.

  • Good point! Thanks, many good answers here – Denny Aug 4 '18 at 7:48
1

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.

  • 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. – timuzhti Aug 6 '18 at 1:30
  • @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. – stefan Aug 6 '18 at 4:32
  • 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. – timuzhti Aug 7 '18 at 2:35
0

This is not a security risk.

If an attacker is logged in as you (or root), and is able to run this command, then they don't need to - they are logged in as you, so they can already run any program as you.

-2

Disclaimer: I don't work in IT, but I do play BOFH when given a chance.

It seems here that the proper solution in a workplace environment is for IT to push out controls/tools/whatever which force all users' machines to run password-locked screenlocks. Disable the specific commands which turn that off. Just keep in mind the unbreakable law "Whenever you make a system foolproof, Nature invents a bigger fool."

  • Luckily most sys admins are smart enough to recognize that once an attacker can run stuff as local users, they've pretty much lost. – vidarlo Aug 4 '18 at 10:17

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.