Every Linux screen locker bypassed with a keypress | Hacker News Reader

Every Linux screen locker bypassed with a keypress

seclists.org

316 pointsJonhoo88 comments

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.

[1] http://mailman.archlinux.org/pipermail/arch-general/2012-Jan...

The headline is simply wrong.

"So from a superficial analysis anything since 1.10.99.902 could be vulnerable."

That's not _every_ linux screen locker. E.g. ubuntu 10.04 isn't affected.

presumably because 10.04 is using an older version, being almost 2 years old now.

I think that was his point. "Every windows machine affected" doesn't mean Windows 7 only.

I think it's pretty clear: "Every Linux screen locker" means every screen locking program that runs on linux, not every version of linux.

The bug is in Xorg, if you have any screen-locker running on a version with the bug, then it can be bypassed.

Even the latest Ubuntu (11.10) isn't affected, having xorg version 1.10.4.

most new distros are. debian-sid uses 1.11

heh, OT rant, ...and i get a email from pg scolding me for using factually correct superlatives in my submissions.

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.

Confirming that Fedora 16 is affected, with the latest updates as of the time of this writing.

Confirmed on Debian Testing

Confirmed with Debian Wheezy (testing). Dell Latitude E6520 has a numpad so screen lock was defeated with simply "Ctrl+Alt+*". :-(

For fedora 16 there is a fix available here https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-0064

  yum update xkeyboard-config

with the Fedora repos enabled fixes the issue now (the fixed in version is xkeyboard-config-2.3-3.fc16.noarch).

Ubuntu 11.04 is not affected either

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?

Even ubuntu 12.04 alpha 1 still uses 1.10.4, so it seems NO ubuntu versions were affected

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 problem is that some versions of linux ship with those modifications in their default keyboard maps. For example, ArchLinux had them until recently in their xkeyboard-config package. http://mailman.archlinux.org/pipermail/arch-general/2012-Jan...

Here is the commit. http://cgit.freedesktop.org/xorg/xserver/commit/?id=7d2543a3...

All the cgit.freedesktop.org links in the seclists thread time out for me. Do they point to the commit or work for others?

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.

[1]: http://cgit.freedesktop.org/xorg/xserver/commit/?id=7d2543a3...

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.

I don't understand the key presses used. Is the "Multiply" key the asterisk (Shift+8)?

And also the + key on the numpad works?

I was unable to get slock to crash, using a US laptop keyboard. :/

Multiply is the key on the numpad that only does *.

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.

It won't work on laptops (most laptops won't have numpad). Ofcourse you can crack into the laptop using an external keyboard.

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.

You can do it on regular laptop keyboard too..

Usually the "numpad" is available via "Fn" key - so make sure that Num lock is on and press `Ctrl+Alt+Fn+*`

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 *.

Most laptops have the Fn button.

Fn+ScrLk is NumLk, and then Ctrl-Alt-8 (on my Lenovo) is exactly the same as Ctrl-Alt-Numpad/8 on a regular keyboard.

slock does not appear to be vulnerable.

don't bet on that, it breaks when I try it. maybe you're using a pre-vuln X.

I wonder if it is because I'm using xmonad.

Nope. Doesn't matter what client apps you are running, this would be an X vulnerability.

Doesn't appear to work on Ubuntu Oneiric. Perhaps because it's running LightDM?

I'm on Oneiric running Kubuntu, and it doesn't seem to work with the KDE screen lock.

Yep, also running Kubuntu Oneiric; nothing.

Edit: Actually, wait, I'm still on Natty. Still nothing though.

Yup, also on 11.04 Natty. Tried with and without Numlock LED turned on, nothing happened.

X-org -version on Kubuntu 11.10 says 1.10.4 and the bug seems to have been introduced in 1.11

So yet to get the killer feature.

Since it's been demonstrated not every Linux screen locker is vulnerable, how about changing the title?

Seems like I'm not allowed to change it anymore..?

Just tried it on Ubuntu 11.10. Did not work.

Same here, 11.10 didn't work

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 not yet obvious it was intentional, to my knowledge.

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?

Switch to one of the consoles and kill the app.

You can usually either get to a tty or ssh in and kill the offending process.

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.

According to the commit in question (http://cgit.freedesktop.org/xorg/xserver/commit/?id=7d2543a3...), the feature either releases all grabs or kills clients which have any active grabs.

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.

Menus seem to cause an X grab. At least, you can't call Ctrl-Alt-L while one is showing.

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.

Key combos:

Ctrl+Alt+* (num pad) Ctrl+Alt+Shift+8

Both with numlock on and off.

I'm using Ubuntu 11.10 and have X.Org 1.10.4; the vulnerability only exists from 1.10.99.902

I often use physlock from X. It drops you to a virtual console and locks from there.

https://github.com/muennich/physlock

I just log out and hit ctrl-alt-f2... sounds similar?

Very interesting. How do you find things like this?

Probably by looking at the source?

Probably by trying to do something like Ctrl+Alt+F1, or Ctrl+Alt+Backspace, or similar stuff, and hitting the wrong key.

Or, by holding Ctrl+Alt and trying out all keys, out of pure curiosity.

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. Android does not use X.

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.

Good point. Sorry to ignore what was already given in the comments. Thanks, though.

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.

Doesn't work in Ubuntu Maverick with X.Org 1.7.5

If you look at the linked post, the vulnerability was introduced in 1.10.99.902, any earlier versions of X.Org are not affected.

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.

Doesn't appear to work on Linux Mint 11 (katya)

Nor on LMDE.

Just tested on Debian sid. Damn, it worked.

It shouldn't: http://security-tracker.debian.org/tracker/CVE-2012-0064

Posted workaround doesn't really work.

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.

No, changing that option doesn't really affect anything.

Never use an X11 screen locker. Use vlock -san. Problem solved, and several other problems with it.

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?

Suspend related problems. There's a thread of similar issues at https://bbs.archlinux.org/viewtopic.php?id=110459

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.

Please can you post the bugzilla bug number for this?

This had nothing to do with GNOME, it was a bug in X that affected any lock application.

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.

Reply on news.ycombinator.com