Slashdot Mirror
Why Screen Lockers On X11 Cannot Be Secure
jones_supa writes: One thing we all remember from Windows NT is the security feature requiring the user to press CTRL-ALT-DEL to unlock the workstation (this can still be enabled with a policy setting). The motivation was to make it impossible for other programs to mimic a lock screen, as they couldn't react to the special key combination. Martin Gräßlin from the KDE team takes a look at the lock screen security on X11. On a protocol level, X11 doesn't know anything of screen lockers. Also the X server doesn't know that the screen is locked as it doesn't understand the concept. This means the screen locker can only use the core functionality available to emulate screen locking. That in turn also means that any other client can do the same and prevent the screen locker from working (for example opening a context menu on any window prevents the screen locker from activating). That's quite a bummer: any process connected to the X server can block the screen locker, and even more it could fake your screen locker.
Flashback from the 90's: Telnet and X11 are inherently insecure - where's the news in that?
... there has to be a trojan on the system or at least something connected to the X server over the network.
Hmm. I think by this time your security is already out the window and a borked lock program is the least of your worries.
I certainly get the technical explanation. Given that I don't think Deskop Linux will EVER be mainstream, this seems like something we've lived with for an incredibly long time, and doesn't affect very many people or systems.
If someone wants to fix it, cool, but it's not really going to bother me very much if this behavior continues.
Do not look into laser with remaining eye.
Isn't the point of a screen locker to keep a person from accessing my computer while I step away for a moment (to go to the bathroom or refill my coffee mug.) not to prevent programs from accessing things?
---Saying gnome 3 is better than windows 8 not so much a compliment as it is damning with light praise.
Would this be the "hobby" OS that took over running the London Stock Exchange trading platform when Windows couldn't cope?
systemd-screenlockerd saves the day!
Of course, it requires systemd-moused, systemd-keyboardd, systemd-windowd, systemd-X11d, and finally systemd-logind. Right now there's some compatibility issues that have been in the bug tracker for a year or so, so for best results you should also ditch KDE or gnome and go with systemd-windowd-managerd and systemd-menud. There's a few incompatible apps as well, if you have problems try using systemd-webbrowserd (requires systemd-networkd) and systemd-xtermd (requires systemd-fontd and systemd-shelld). Thunar works fine though for browsing files, as long as they're in the systemd folder.
If I have been able to see further than others, it is because I bought a pair of binoculars.
KDE uses QT, a gigantic toolkit, to implement the screen saver. In this case the UI relies on QT Quick.
Gnome's screensaver has the same problems with GTK.
Jamie Zawinski, who wrote the standard xscreensaver, has a FAQ page detailing how these are a fundamentally bad idea from a security perspective:
http://www.jwz.org/xscreensaver/toolkits.html
Whats being attacked is the unix ethos: do one thing and do it well. Capturing the key sequence to lock and faking the screen, while it may be easier in KDE alongside Systemd, is not easy in fluxbox or awesome. Its the explicit lack of widgets or sprockets or mindless dreck like this, and predefined key sequences that are captured by the window manager first. I use i3lock, which would mean attackers would have to find a way to get into /usr/bin to usurp my locker and at that point i have a far greater degree of concern than just the locker. X Forwarding and shared X in general has always been a security concern. ssh-agent should be avoided and if you have work to do on the server, do it in a tty over ssh. And this is the schism: newschool linux wants a sexy user experience that pops out of the box and is unified. They want the user to obey the vision of their design and use user switching, connection sharing, and fancy clock widgets and X just cant be (nor should it) Microsoft Windows. Old fogeys like myself will deck the halls of localhost when and if we want to. And it will always be on our terms, right down to color, shape, and font. Security will be our concern.
Good people go to bed earlier.
They did go for C++. On Linux. It was more than just issues with .NET.
Article is WRONG WRONG WRONG. Screen locker: issue chvt onto another X instance, and spawn a thread that goes into a loop reissuing chvt to hold it there until the unlock password is given.
vlock -asn
This has been solved for a long time. Not sure why this is really an issue.
Comparing this to Windows is silly, because Windows doesn't have anything like the X11 protocol. On Windows, running code can disable the screen saver in other ways: patching or replacing DLLs, changing system configuration, etc. No difference from a security point of view.
I'm no Windows fanboy, but this is just factually incorrect.
(1) All those operations require elevation, so unless the user has lowered UAC from the default, they will require authentication. I suppose a malicious installer could do that, but it is emphatically incorrect that any running code can effect that change.
(2) Since 7, when Windows elevates it completely suspends the old 'Desktop' and creates a brand new one for the elevation prompt. If you look closely, you'll realize that all the other 'windows' are actually just a static screenshot of what happened on the unprivileged desktop at the point where the elevation prompt was created.
So "from a security point of view", on Windows you have a specific privilege required to change the SS that is mediated through a privileged interface where it cannot be snooped/intercepted by unprivileged processes.
[ Of course, this comparison is also patently unfair -- Windows 7 was written in the 2000s, X11 was written in the 1980s. Expecting them to be comparable in terms of security is pretty ridiculous. ]
http://www.jwz.org/blog/2014/0...
Perl Programmer for hire
If it has access to draw windows in your X session, it's elevated plenty - it can also log keystrokes at that point.
The year of the Linux desktop was several years ago. Most new computing devices run Linux, and fit in your pocket.
I'm not familiar with writing apps for X, but are you saying that every program that displays a window in X can log all keystrokes including in windows that are not associated with that program?
If so, I'm staying away from X for now on.
If not, I'm not sure what your point is. The malicious application would need to display a fake lock screen, convincing enough to fool the user, before the user would type in their credentials. Only then would that app be able to elevate.
All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
Are you familiar with the traditional attack
Computer somewhere running some OS.
Regular authorized but non-priviledged user logs in and runs regular non-priviledged user-space application "program that looks like lock screen" and then leaves computer.
Another coworker, or perhaps an administrator walks up to use the computer; types in his credentials... and the app saves them...
Windows solution to the attack implemented decade(s) ago:
real windows desktop lock screen can only be unlocked with ctrl-alt-delete which user-land non-priviledged apps can't intercept.
train users never to login to a computer unless they hit ctrl-alt-delete to unlock it first.
Jamie Zawinski has another explanation why screensavers on KDE can't be secure:
Like GNOME, KDE also decided to invent their own screen saver framework from scratch instead of simply using xscreensaver.
And Unity:
Guess what, they did it again! Ubuntu Unity's screen-locking framework is yet another rewrite, and it is completely broken, bug-ridden and insecure. At this time I don't have any information on how to turn it off and use xscreensaver instead. If you do, let me know.
He also has a writeup on toolkits, discussing why locking and unlocking is a hard problem, especially when accessibility features are required.
Ask me about repetitive DNA
I'm not familiar with writing apps for X, but are you saying that every program that displays a window in X can log all keystrokes including in windows that are not associated with that program?
Yes. This isn't just X, by the way; it's a common design across most operating systems. Any client can register to receive keyboard and mouse input regardless of the current focus, unless another client has already "grabbed" the input device. This is how things like global keybindings are typically implemented. Windows used for password entry (including lock screens) can grab the keyboard to prevent other programs from listening in. The problem is that this only works if no other program has already grabbed the keyboard.
Secure input handling is one of the many reasons why everyone is eventually planning to switch to Wayland. Under Wayland, only the compositor has access to the raw input or the ability to inject simulated input events. The compositor manages any global keybindings and forwards the remaining events exclusively to the active window.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
Security standards like PCI DSS assume that, yes, your users are untrustworthy or, at best, naive.
Gamingmuseum.com: Give your 3D accelerator a rest.
Jamie Zawinski has been wrong before, too, but in this case it's not even wrong. What we're talking about is the X protocol being fundamentally flawed; it's really pretty irrelevant what screen locker is being used.
And yet Jamie's xscreensaver hasn't been shown to be insecure by this guy. He's only proven what jwz said which is that a lockscreen using a toolkit on top of X11 is insecure.
Let me get this straight. In order to exploit this vulnerability, an attacker must:
* gain login access to your system via SSH
* hope you turned on X11 forwarding
* be root or your user
* hope you've disabled access control with `xhost +`
* be able to run a fake screen locker program to get your password to the system he's already completely compromised
Yes, someone could still stop by your desk and put in the fake screen locker while you were getting coffee, but if you got up and didn't lock your machine, that's on you, not X11.
I'll file this one under "good enough" security.
6th Street Radio @ddombrowsky
You're tricking yourself into security theater. You can't intercept an actual ctrl-alt-del, but you can read the ctrl and alt keys, and just unlock your fake lock a couple seconds later. For bonus points, as soon as they press ctrl-alt you change the pointer to an hourglass, and wait an extra second, that way even if they're slow they have time to press del. No windows user is going to be surprised or alarmed by 2 seconds of lag. Their brain will probably hold them in a sort of pause mode anyways, because they're so used to waiting to be allowed to continue.
And the more often they have to press a magic key combination, the more robotic it becomes and the less attention they will pay. Also, even if something looks slightly off, they've been taught that this magic key protects them in this situation, so they won't worry much.
Some other window most likely does have the keyboard focus, but that's not the same as grabbing the keyboard. Having the focus doesn't prevent input events from also being delivered to other windows, it just tells the non-focused windows to ignore the events. Integrity and privacy for both input and output is a hard problem and something very few windowing systems manage to get right. The solutions tend to involve some degree of inconvenience for the user.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
The basic misunderstanding here is the idea that the screen lock in old X was designed for security, and usable as such; it was just a screensaver with a password
What use is a screensaver with a password that isn't designed for security? Why is the password even there? So it looks secure? Lets just admit it was poorly designed from a security standpoint. That's fine, most stuff designed at that time was not secure. MS-DOS had no security at all. Pointing out that NT occasionally has some good ideas is not an indictment against Unix.
Your façade rather falls apart when they actually do press "del", I think.
It was more than just issues with .NET.
Really? Now I'm interested. What other problems did they have?
Messaging systems performance. The closed nature of the windows kernel means it cannot be tuned to the granularity required for performance objectives to be met for the messaging systems. Windows may reign supreme on the desktop, however when it comes to serious computing objectives, it's always the year of the *ix server.
As for this issue affecting any enterprise systems, many don't have a GUI on their console, so there is no opportunity to troll there either.
Incidentally, if you want to see a manifestation of this issue on a X11 desktop, pick a program with menus - lets say firefox, position the mouse on the menu so it opens, then leave the cursor on the menu until the screensaver kicks in. After the lock screen kicks in you will be able to interact with the GUI until the task loses focus, then the screen save will lock. It's been around for a while.
Yep, it's a risk for a desktop, if _insert_convoluted_scenario_here_, however it should still be fixed.
My ism, it's full of beliefs.
I'm not familiar with writing apps for X, but are you saying that every program that displays a window in X can log all keystrokes including in windows that are not associated with that program?
Yes. This isn't just X, by the way; it's a common design across most operating systems. Any client can register to receive keyboard and mouse input regardless of the current focus, unless another client has already "grabbed" the input device.
Except in Windows. Since Vista user interface privilege isolation prevents unauthorized processes from grabbing keyboard/mouse events or sending messages to windows owned by another process, even if that process is running as the same user. To be allowed to grab keyboard/mouse, the process must have declared that intent in the manifest *and* it must have been launched from an installed location (program files or windows system). Furthermore, such hooking/messaging is also masked out at the intrinsic level by UAC - specifically by integrity levels. A lower integrity process is simply not allowed - manifest or not - to send messages or install keyboard/mouse hooks at a higher integrity level process.
X is especially bad in this regard, as it does not even protect against shatter attacks and eavesdropping on windows from *another users* processes. If you elevate to root - e.g. sudo from a terminal window - any other process can *still* eavesdrop on keyboard events.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
But when you do actually press the Del key, the real password dialog appears, and it is on a secure desktop (the "Winlogon" desktop) that can't be manipulated by your rogue program. Your window would be seen only after the user entered their password once, which would look quite suspicious.