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.
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.
If someone gets physical access to my machine while I'm away and the screen locker has not activated, regardless of OS I am on, I am screwed. Be it Windows where a utility can be run to hook into the keyboard, OS X and a .kext that flashes a custom ROM to the keyboard so it doubles as a keystroke logger, AIX could have the bootlist modifed to boot from an unauthorized rootvg, Solaris could have the root role moved to all users, and so on.
Realistically, X-Windows authentication and running rogue clients has been a non-issue since the late 1990s. By default, X is locked down quite tightly, taking an explicit "xhost +" to undo those measures. Even when SSH-ing into a remote machine, by default, the X-windows port is not authorized or forwarded unless both the client and server are explicitly changed to permit this. These days, relatively few applications are X-windows clients, other than legacy stuff. Most enterprise level items (be it an Isilon, VNX, VMWare vSphere, tape silo, and so on) either have a dedicated client, allow SSH in, or have a web page for their configuration. The last time I've used a X-Windows client from a remote machine was running the NetBackup administrative client application from a master server, because it was the most reliable way I could watch what was going on.
One cannot make light of security holes, but there are things to work on and ones that are too difficult for an attacker to ignore. It takes some explicit commands to force X-windows to allow clients other than from the local machine to connect (including disabling the kernel packet filter or actively allowing connections through it.) So, someone connecting remotely to an X server before xlock activates can be a hole... but it is something extremely hard to take advantage of.
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
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
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.