Every Linux screen locker bypassed with a keypress

http://seclists.org/oss-sec/2012/q1/200

by Jonhoo • 15 years ago

316 88 15 years ago

tmhedberg• 15 years ago

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

NanoWar• 15 years ago

Very interesting. How do you find things like this?

udp• 15 years ago

Probably by looking at the source?

vog• 15 years ago

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.

cbs2• 15 years ago

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.

naner2• 15 years ago

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. :/

Dylan168072• 15 years ago

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

ericmoritz• 15 years ago

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.

sagarun2• 15 years ago

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

bcl2• 15 years ago

slock does not appear to be vulnerable.

tsewlliw• 15 years ago

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

Dylan168072• 15 years ago

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?

gst• 15 years ago

Switch to one of the consoles and kill the app.

leif• 15 years ago

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

CGamesPlay2• 15 years ago

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.

secure• 15 years ago

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.

Tobu• 15 years ago

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

nitrogen• 15 years ago

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.

simmons• 15 years ago

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! :/

CPlatypus• 15 years ago

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.

Ubersoldat• 15 years ago

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

jgeralnik2• 15 years ago

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.

machrider• 15 years ago

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.

cookiecaper• 15 years ago

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.

regularfry• 15 years ago

It's not yet obvious it was intentional, to my knowledge.

sirclueless3• 15 years ago

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.

stewbrew• 15 years ago

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.

mindstab• 15 years ago

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

watty• 15 years ago

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

Sharlin• 15 years ago

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

gcb• 15 years ago

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.

_ea1k• 15 years ago

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.

johno215• 15 years ago

Ubuntu 11.04 is not affected either

lepht2• 15 years ago

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?

boutch55555• 15 years ago

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

zalew• 15 years ago

Just tested on Debian sid. Damn, it worked.

babilen• 15 years ago

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

mrb• 15 years ago

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!

lucian1900• 15 years ago

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

rufugee• 15 years ago

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

buu700• 15 years ago

Yep, also running Kubuntu Oneiric; nothing.

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

lewstherin• 15 years ago

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.

Tinned_Tuna• 15 years ago

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.

jgeralnik2• 15 years ago

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

patricklynch• 15 years ago

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

pcvarmint• 15 years ago

Nor on LMDE.

utefan001• 15 years ago

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

slipperyp• 15 years ago

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

lepht2• 15 years ago

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

mrinterweb• 15 years ago

Just tried it on Ubuntu 11.10. Did not work.

mrpollo• 15 years ago

Same here, 11.10 didn't work

clebio2• 15 years ago

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?

CGamesPlay2• 15 years ago

No. Android does not use X.

simcop2387• 15 years ago

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.

clebio2• 15 years ago

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

dazbradbury• 15 years ago

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.

shmerl2• 15 years ago

Posted workaround doesn't really work.

cbs2• 15 years ago

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.

shmerl2• 15 years ago

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

zokier• 15 years ago

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.

sirclueless3• 15 years ago

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

rbanffy• 15 years ago

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

Jonhoo2• 15 years ago

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

drivebyacct2• 15 years ago

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.

nodata• 15 years ago

Please can you post the bugzilla bug number for this?

Jonhoo2• 15 years ago

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

literalusername3• 15 years ago

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

Adaptive3• 15 years ago

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.

literalusername3• 15 years ago

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?

Adaptive3• 15 years ago

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

https://github.com/muennich/physlock

code_duck• 15 years ago

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

Every Linux screen locker bypassed with a keypress

Related Stories