For Arch Linux users, a patch has already been applied [1] to the xkeyboard-config package in [extra] this morning which corrects this issue by disabling the problematic "debug keys" in the X keymap. Update your system and restart X, and the issue should go away.
I took the 'every' portion to mean that every screen locker is affected on the vulnerable versions of Xorg server, not that every version of Xorg is affected.
Meaning that any version of any of Gnome/KDE/XFCE/etc's screen lockers will be defeated by this exploit if they are running in this version of Xorg.
As far as I can tell this is probably true, unless someone knows a locker that uses an alternative method of locking out all keyboard/mouse input?
It would be interesting to see which distros are and are not affected. If Fedora 16 is unaffected, I'm going to disagree with your assertion that "most new distros are". Debian stable is unaffected, for example, so the production Debian builds aren't vulnerable.
How did this happen? I mean, I understand the debug key combinations, but how did they get mapped to actual keys? The commit says To use these, you need to modify your XKB maps.
The offending commit[1] loads fine for me, but I'd rather not call out some poor OSS contributor by name here.
My question is: what is the actual function/line that causes the screen lock to die? My C knowledge is close to non-existent, but the ungrab all function looks a bit suspicious. Some commentary by someone who understands what's going on here would be appreciated.
X11 screen lockers (usually) work by filling the screen and grabbing all keyboard and mouse input. The UngrabAllDevices function interferes with this functionality, and optionally kills the "offending" process.
Said functionality is entirely intentional, although presumably the author didn't consider the implications outside of a debugging context.
It's the * numpad key, Ctrl-Alt-Shift-8 doesn't work but if my coworker turns on numlock and does Ctrl-Alt-* with the numpad key the screen lock turns off.
Most laptops have a way to use the numpad equivalent by holding down the function key, though I don't have a laptop in front of my to verify that it will still bypass the screen locker with the command.
My Compaq laptop has an embedded numpad, located in the vicinity of the right hand home row. The numpad keys are noted as a key symbol inside a square.
Set numlock will enable the numpad keys by default. If numlock is not set, then fn-numpadkey gets the numpad version of the key pressed. E.g. fn-p is *.
Man, that is pretty crazy. Ctrl+Alt+* and the whole screensaver goes away just like that and everything on the workstation is accessible. Glad this vulnerability is getting more attention; I think it's obvious the feature should only be enabled in debug builds.
It's pretty obvious that it wasn't intentional. Or rather, that there was some miscommunication. Someone added a debugging feature that gets rid of programs that have grabbed the screen, and which is enabled by mapping some key combination to a function. They probably realized this was dangerous to enable generally. Someone else saw the recommended key combination and packaged it for general distribution, not realizing that it was a dangerous function that shouldn't be mapped ordinarily.
Of course, if you think you are safe because your keyboard does not have a numeric keypad: you are not. The attacker can just plug in a USB keyboard with a numpad and use it. Yay plug-n-play!
While this may be a 'debug' feature it sounds useful for when a fullscreen app locks up. If not these key combinations, what are you intended to do in such a situation?
I'm fine saying that, for a lock screen, you need to reboot. For any other fullscreen app, I'd expect Ctrl+Alt+Fn to take you to a tty, where you could kill any apps.
A regular fullscreen application (such as MPlayer, VLC, Chromium, …) does not grab the keyboard and/or pointer. However, applications like pinentry-gtk (for things like entering your GPG passphrase) or screenlockers do grab the keyboard and pointer.
So, in short: no, this doesn’t seem useful in that case. And what you are usually intended to do is use the shortcuts of your window manager to kill the window/application or switch to a different workspace/desktop with a shortcut and kill the process from there.
A regular fullscreen application (such as MPlayer, VLC, Chromium, …) does not grab the keyboard and/or pointer.
Regular fullscreen games do, however. If there were some way to distinguish between a lock screen and a game, it would be worthwhile to keep the feature around.
Indeed -- I've often manually set AllowDeactivateGrabs in xorg.conf just so I can use ctrl-alt-/ to kill poorly written programs that XGrabKeyboard() then freeze. Of course, my workstation is physically secure so I don't need the screen lock.
AllowDeactivateGrabs, and its sister option AllowClosedownGrabs which enables ctrl-alt-* to close apps with an active grab, have long been known to be a security hole that the user must explicitly enable. I'm surprised distributions are now somehow shipping with these options enabled! :/
I attempted to replicate this (attempted being the operative word, I could've been doing it wrong) with Ubuntu 11.10 and a GB keyboard layout. It didn't seem to work.
Ctrl-Alt-Multiply is a known key shortcut. Someone just has to know it exists and think "I wonder what happens if I use this while the screen is locked". You can get to that internal question many different ways, but its worth mentioning on top of that, security minded have trained their brains to be good at serendipitously coming up with "what happens if I do X and X" questions.
For some reason, I read 'Android' when I scanned this headline. But since Android is a linux variant, would this be possible? My phone doesn't have a physical keyboard, but maybe the Asus Transformer with the attachable keyboard, for example?
No, this is an issue specifically with the way X11 works with the Xorg server. Android doesn't use X11 so would be unaffected by this particular issue.
Whilst not the same, on my HTC desire z (which has a physical keyboard), the two programmable keys on the keyboard work even when the screen is unlocked (you unlock to find that action has occurred) . Obviously, this is less of an issue, but one nonetheless.
In other words, terrible headline on this post. I imagine Arch and Gentoo are the most likely to be affected, as they tend to run bleeding edge projects. Most Linux users are unaffected.
My machine runs Gentoo and it's not affected -- because it runs an older version of Xorg.
Just because the bleeding edge version of Xorg is available on Gentoo doesn't mean you're forced to use it. You can always decide not to upgrade and stay with an old version of anything.
On the other hand, if you stay with old versions too long, things might break when you finally do try to upgrade.
I've did a bit of googling about this and ran across something that might work (but I haven't tried it), adjust the AllowClosedownGrabs option in your xorg.conf file.
I used vlock for a long time but there were some hangups that caused me to switch to physlock (mentioned above, but here's the URL: https://github.com/muennich/physlock ). It's in Arch's AUR.
I've been very happy with vlock. What hangups did you run into? I admit that it has required some scripting to avoid launching it twice concurrently (via xautolock and pm-utils), and to clear its console before locking, but overall I find it secure, elegant, and worthwhile. What do you prefer about physlock?
physlock also eliminated some of the scaffolding code to deal with the multiple launches, etc. It's just a better tool solving the same problem. Recommended.
Thanks for the recommendation. I'll definitely bear it in mind for future installs, but since I put the effort into configuring vlock well, I'd like to live with it for a while more. I'd actually already read that thread when configuring vlock on my current box, and I do chvt $(cat /tmp/console.pm) on resume. It's robust when configured well, but I can see the value in a locker that requires less configuration time.
Just reminds me of more usability/security concerns in GNOME.
If you have any popup dialog box open anywhere, it completely inhibits the screensaver. Try it. Open Rhythmbox and open the volume slider and walk away from your computer. Open Chrome and open the Google Voice popopen box. Your computer will not go to sleep. Also, it breaks mouse focus and more. The GNOME developers don't seem to care at all.
I tried this on my very recently installed Fedora 16 desktop at home, and it worked. All of my applications were accessible, alt-tab and other selection methods worked, etc. The only thing that was missing was the panel at the top, and I couldn't be bothered figuring out how to bring it back so I just rebooted. Good thing I don't rely on that feature too much.
[1] http://mailman.archlinux.org/pipermail/arch-general/2012-Jan...