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.
What? I was assured that THIS was the year of the Linux Desktop!
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.
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. ]
The year of the Linux desktop was several years ago. Most new computing devices run Linux, and fit in your pocket.
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
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
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*