Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Security X Linux

Why Screen Lockers On X11 Cannot Be Secure 375

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.
This discussion has been archived. No new comments can be posted.

Why Screen Lockers On X11 Cannot Be Secure

Comments Filter:
  • by heavy_metal_drinker ( 3941369 ) on Wednesday January 28, 2015 @12:51PM (#48924721)
    Flashback from the 90's: Telnet and X11 are inherently insecure - where's the news in that?
  • by Viol8 ( 599362 ) on Wednesday January 28, 2015 @12:51PM (#48924723) Homepage

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

    • by TWX ( 665546 )
      Well, one of the flaws in X11 is how one receives remote screens to your X-server, and if people allow localhost to send screens to the session, then if someone compromises a local unprivileged account they could set up a fake lock screen on an admin's session so that when the admin enters his password they get the text he typed.

      I see how this could be a problem, but given that desktop Linux isn't all that widespread I see bigger problems in arenas that are much more pressing.
    • FUD (Score:2, Troll)

      by Flavianoep ( 1404029 )

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

      Thank you! Now I can be sure that these "news" are just FUD.

      • by Burz ( 138833 )

        Its not FUD when a malware (or bug) with normal privs can open an avenue for physical attack.

        If a website/MITM tricks your browser into putting up a tiny context menu, it can allow someone to walk up to your computer later and start messing with it.

    • by bondsbw ( 888959 )

      Hmm. I think by this time your security is already out the window and a borked lock program is the least of your worries.

      Just because an application is running on your system doesn't mean it has elevation. But if it pretends to be your lock screen and convinces you to put your password into it, it may be able to gain that elevation.

      • If it has access to draw windows in your X session, it's elevated plenty - it can also log keystrokes at that point.

        • by bondsbw ( 888959 )

          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?

          If so, I'm staying away from X for now on.

          If not, I'm not sure what your point is. The malicious application would need to display a fake lock screen, convincing enough to fool the user, before the user would type in their credentials. Only then would that app be able to elevate.

          • 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?

            Well try this:
            - Find the id of your window of interest (xwininfo).
            - Attach to it with xev -id $id

            Now that you know ... Ctrl-Alt-Backspace zaps X.

          • by JesseMcDonald ( 536341 ) on Wednesday January 28, 2015 @02:55PM (#48926131) Homepage

            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.

            • by benjymouse ( 756774 ) on Thursday January 29, 2015 @03:29AM (#48930197)

              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 [wikipedia.org] 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.

        • by vux984 ( 928602 )

          Are you familiar with the traditional attack

          Computer somewhere running some OS.
          Regular authorized but non-priviledged user logs in and runs regular non-priviledged user-space application "program that looks like lock screen" and then leaves computer.

          Another coworker, or perhaps an administrator walks up to use the computer; types in his credentials... and the app saves them...

          Windows solution to the attack implemented decade(s) ago:

          real windows desktop lock screen can only be unlocked with ctrl-alt-delete w

          • Here's the problem: if you care about security to the point where screen locks are serious business, you've gotten yourself into a contradictory set of requirements: both trusted and untrusted users have physical access to and execution priveleges on a terminal. If you really suspect that your users are untrustworthy enough to steal credentials in this way, the answer is to not have a screenlock at all but to push the security barrier further into the system. The terminal is dumb and has no security model,
          • You're tricking yourself into security theater. You can't intercept an actual ctrl-alt-del, but you can read the ctrl and alt keys, and just unlock your fake lock a couple seconds later. For bonus points, as soon as they press ctrl-alt you change the pointer to an hourglass, and wait an extra second, that way even if they're slow they have time to press del. No windows user is going to be surprised or alarmed by 2 seconds of lag. Their brain will probably hold them in a sort of pause mode anyways, because t

  • Uh, okay? (Score:2, Insightful)

    by TWX ( 665546 )
    I certainly get the technical explanation. Given that I don't think Deskop Linux will EVER be mainstream, this seems like something we've lived with for an incredibly long time, and doesn't affect very many people or systems.

    If someone wants to fix it, cool, but it's not really going to bother me very much if this behavior continues.
    • by Enry ( 630 ) <.ten.agyaw. .ta. .yrne.> on Wednesday January 28, 2015 @12:55PM (#48924773) Journal

      What? I was assured that THIS was the year of the Linux Desktop!

      • by TWX ( 665546 )
        Every year is the year of the Linux desktop. And none of them are.
        • It doesn't bode well for Linux that it is also not the year of the Windows Desktop or Apple Desktop. It is the year of the smart phone. The year of the desktop may never return. Desktops are better suited for developers and smart phones are better suited to consumers.
          • by Kjella ( 173770 )

            It doesn't bode well for Linux that it is also not the year of the Windows Desktop or Apple Desktop. It is the year of the smart phone. The year of the desktop may never return. Desktops are better suited for developers and smart phones are better suited to consumers.

            Developers and a ton of other professionals. If Linux/FLOSS could replace Windows, Office, Outlook/Exchange, Sharepoint and SQL Server that's probably 15 of Microsoft's $26 billion dollar revenue. Open source has not managed to commodify basic business and collaboration tasks, despite so many years of trying. It's not all about smartphones and tablets.

        • No no, that is a misunderstanding. This year is the year of a linux desktop. Not The linux desktop.

      • by bondsbw ( 888959 )

        It is. They just failed to mention that it was is a year on Pluto.

      • It is the year of the Linux desktop! It's just that the Linux in question uses Chrome instead of X11 as its GUI.

      • by jfengel ( 409917 )

        They had to push that back. This is the year of Linux on the Flying Car. We'll get to Linux on the Desktop right after that.

      • It is! Unfortunately the Desktop is itself rapidly fading in favor of the laptop, and desktop Linux has power management issues that make it substantially less suitable for mobile applications..

    • by raymorris ( 2726007 ) on Wednesday January 28, 2015 @02:00PM (#48925593) Journal

      The year of the Linux desktop was several years ago. Most new computing devices run Linux, and fit in your pocket.

    • What about Steam on Linux, Microsoft charging a yearly subscription for Windows 10*, and nobody wanting to pay to continue using the computer they already bought?

      *Windows 10 upgrades within the first year of release come with a free lifelong subscription until Windows 10 is discontinued. Corporate subscription is per-user on unlimited devices, rather than per-device.

  • not the point (Score:4, Insightful)

    by lister king of smeg ( 2481612 ) on Wednesday January 28, 2015 @12:56PM (#48924795)

    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?

    • The problem is that if you walk away and think that the screen locker will kick in, and somebody comes by while it is still unlocked, they can run a program that will look the the screen locker when you come back, but in reality will actually just be recording your user name as password so the intruder can use this. They'll get the password, and come back at a time when they have more time to do their dirty work. Ideally, you should lock your computer as soon as you get up, but that's what happens in an id
      • Re:not the point (Score:4, Informative)

        by Anonymous Coward on Wednesday January 28, 2015 @01:17PM (#48925089)

        What do you mean "think it will kick in"? Activate it when you get up from your desk, period. For Windows it's an easy "winkey+L" combo as you get up from your desk. Done, workstation is secured and locked. That's our company policy anyway, you're supposed to lock your workstation when you step away. A timed lock screen is pointless, stupid and just gets in the way. If your mouse just happens to bounce a little, it'll reset the "inactive screen timeout".

        • If you have a laptop it will usually lock when you close the lid, but as the summary said, if a context menu is open it might be prevented. The same when you click the lock key, if you don't check and see that it really launches and locks the screen, it might be that it is not locked.

        • by Kaenneth ( 82978 )

          I don't have a Windows key, you insensitive clod.

          (IBM Model M keyboard from 1996)

      • Re: not the point (Score:3, Informative)

        by Teranolist ( 3658793 )
        Thats why you lock your screen manually BEFORE you leave the machine...
        • by Lumpy ( 12016 )

          Not mine, when I get up the prox card reader sees that I am not near the workstation and instantly locks, it will not even offer an unlock until I am within proximity again.

          Really cheap to put in place less than $10K for the whole company. and increases security 80 fold. Problem is most IT departments are not savvy enough to do it nor convince management that it's more important than a new Jaguar for the Director of marketing. Heck my old Dell laptop supported it.

      • but in reality will actually just be recording your user name as password so the intruder can use this. They'll get the password, and come back at a time when they have more time to do their dirty work.

        That's why I always first try to unlock with "password123" when I get back from the bathroom break I could no longer postpone.

      • Re:not the point (Score:4, Interesting)

        by mlts ( 1038732 ) on Wednesday January 28, 2015 @02:08PM (#48925669)

        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.

      • Those bluetooth locker programs are handy for this, once your phone / headset / whatever is out of range of your computer the lock screen automatically comes on. Some can also be configured for unlock (though that seems like it would add another possible attack surface).

        I feel like there would be a market for small bt keychain dongles for this exact purpose.

    • Yes. What you see here is feature envy.

      Windows used to have so many keyloggers (it was really insecure around 1999 and 2000) that they added the ctrl-alt-delete functionality to make sure only the Windows kernel could grab your password when you logged in, not some keylogger. Now these guys are feeling jealous about that.

      I've heard of this as a justification for replacing X11 with Mir/Wayland or whatever, but obviously if this is a desired feature, the solution is to merely add an extra function call t
      • by smash ( 1351 )

        "merely add a function to the X11 API" is the problem. X11 is ancient, full of bloat that no one uses any more and not designed with core concepts in mind that are desirable in a modern operating system. Really, look up some youtube presentations from the Wayland guys - who actually work on X11 and listen to what they have to say regarding the complexity and brain damage in X11. It works, but sometimes, even the guys who maintain it don't know exactly why.

        The X11 display server is a liability and need

        • Good luck ever actually getting rid of it, considering it is what every *nix gui app runs on. Even if the switch to Wayland happens, most people will still be stuck with using XWayland constantly for a decade.

          • by rgmoore ( 133276 )

            Even if the switch to Wayland happens, most people will still be stuck with using XWayland constantly for a decade.

            They may be stuck with XWayland for a handful of apps that aren't being updated, but the work to let modern desktop environments run on Wayland instead of X11 is quite far along. Once the basic KDE and GNOME libraries are ported to Wayland, anything that uses those higher level libraries rather than talking directly to X will run under Wayland without needing any intermediary like XWayland. I

          • by DrXym ( 126579 )
            "Good luck ever actually getting rid of it, considering it is what every *nix gui app runs on. Even if the switch to Wayland happens, most people will still be stuck with using XWayland constantly for a decade."

            Virtually every *nix app runs over abstraction layers such as QT, GTK, Pango, Cairo etc. Assuming there are wayland backends for these layers then porting isn't as hard as you think. There may be vestigal bits of X to clean up and some edge cases that need more effort (screengrabbers, video players

        • Oh, Wayland........maybe after I do systemd, I'll work on a code review of Wayland. :)

          All the same, if some guys can't figure out how their code works, I don't really expect them to go out and do something better in another project. I expect them to make the same mistakes again. Joel makes some good points [joelonsoftware.com]. He says,

          "when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don't even have the same programming team that worked on version one, so you don't actually have "more experience". You're just going to make most of the old mistakes again, and introduce some new problems that weren't in the original version. "

          Maybe Wayland will be better, that would be great. Odds are against it though, because of how rewrites usually go.

          • I don't know - every program that I've ever restarted from scratch has turned out far more powerful and flexible with a far smaller codebase than the original. Lessons learned from the first go-round and all that. With a better understanding of the problem space comes a better ability to address it efficiently.

      • by Scoth ( 879800 )

        Windows has had the ctrl-alt-del to log in/unlock since literally the first version of Windows NT, 3.1, in 1993. That's a long time to have feature envy, though I suppose it's possible. I generally wonder if the average user is clever enough to understand the implication anyway - if you put up a fake login dialog on Windows just past the ctrl-alt-del, I bet most users would just fill it out and go with it rather than think they're under attack.

      • by DrXym ( 126579 )
        "the solution is to merely add an extra function call to the X11 API rather than rewriting the whole thing. Problem solved, if there is one."

        X11 is an arcane and largely obsolete framework. The fact it needs so many damned extensions to be any way functional is precisely the reason that developers are keen to get rid of it. It's not secure, it's filled with arcane and obsolete code and it's terribly inefficient both locally and remotely. Fortunately it'll be moved aside and replaced by wayland over the ne

    • Example that might make more sense:

      You download a program that appears legit (and may be mostly legit, or be a hacked version of a legit program), and are running it.

      The program senses inactivity, opens a contextual menu on the screen to prevent the REAL screensaver from kicking in, and opens it's own fake screensaver instead.

      When you get back to the computer, it prompts you to input your credentials.

      Voila... it now has your credentials, and can wreak utter havoc and destruction (depending on your permissio

      • You download a program that appears legit (and may be mostly legit, or be a hacked version of a legit program), and are running it.

        But why would I do that? Almost all the programs I use come from the repository, and to get me to download one they'd have to compromise the repository first (which is possible, but not nearly as easy as just advertising a program for download). The rest are again ones I download from known sources, usually the developers' own official site, and again it's not trivial to comprom

        • You download a program that appears legit (and may be mostly legit, or be a hacked version of a legit program), and are running it.

          But why would I do that? Almost all the programs I use come from the repository, and to get me to download one they'd have to compromise the repository first (which is possible, but not nearly as easy as just advertising a program for download). The rest are again ones I download from known sources, usually the developers' own official site, and again it's not trivial to compromise those sites.

          The situation you propose only happens in the world of Windows where downloading random software from untrusted/unknown sources is routine. And if you're routinely doing that, you've got more problems than just a way to bypass the screen lock. The best way to avoid shooting yourself in the foot is to not blithely follow instructions but to stop and ask "Wait a minute, why are they asking me to aim a loaded gun at my foot and pull the trigger?". And if after pondering that question you still think following the instructions is a good idea, please report to HR for reassignment as reactor shielding.

          Exactly. I just looked at my programs list installed 99% of non game software came from the repository, the games were installed via steam which is in turn in the repository. the remainder (vmware player, and chrome) is delivered via HTTPS from the official site or from the git repository.

      • Well, yes.

        However, that only works if the attacker already has arbitrary local code execution. If they can do that then they can trojan every single program, by diddling with the PATH environment variable and/or pissing with LD_PRELOAD.

        Basically yes, it's a hole but one that only kicks in if you're fucked 6 ways to Sunday already.

        Or if you've done xhost+ and disabled your firewall. But that hasn't been the default in years.

    • by jythie ( 914043 )
      Pretty much this. Security often involves a trade off, and this type of screen locking performs well for the level of security it was intended to establish.
  • by Qzukk ( 229616 ) on Wednesday January 28, 2015 @12:59PM (#48924847) Journal

    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.

  • physical access (Score:2, Insightful)

    by silfen ( 3720385 )

    Screen lockers protect against physical access; you're welcome to try and get around an X11 lock screen by tapping at the keyboard. Good luck.

    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.

    • Re:physical access (Score:5, Informative)

      by Wrath0fb0b ( 302444 ) on Wednesday January 28, 2015 @01:33PM (#48925285)

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

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

        Which could be a good argument for replacing X. It is rather old technology, perhaps it is time to update it to something newer, rather than clinging to it and claiming it is all one needs.

        • Which could be a good argument for replacing X. It is rather old technology, perhaps it is time to update it to something newer, rather than clinging to it and claiming it is all one needs.

          Or how about adding a protocol extension to deal with this security problem as has been done a number of times in the past for authentication. I don't understand why X11 seems to get special treatment here.

          Program has security flaw. Response "has it been patched yet"

          X11 has security flaw: we can't possibly patch it we mus

      • by Alomex ( 148003 )

        X11 was written in the 1980s

        Written? More like scratched in crayon in the walls of a padded cell.

        The architecture of X has always been a mess going back to the very beginning. Need proof? the client is on the server and the server is on the client. 'nuf said!

        p.s. notice that you need no elevation for this. This was a common joke back in the pre-security days. You wrote a cool user space application that after a few minutes of inactivity would pop up an xlock clone. The user would then type his/her password and "unlock the screen".

        The

    • by unrtst ( 777550 )

      Screen lockers protect against physical access; you're welcome to try and get around an X11 lock screen by tapping at the keyboard. Good luck.

      1. CTRL+ALT+Backspace
      2. CTRL+ALT+F1, CTRL+ALT+F2, ...
      3. ALT+SYSREQ+F
      4. CTRL+ALT+KP_MULTIPLY

      Maybe you're safe from all those because you disabled all the features that make those work. Are you sure you're safe? Now try "vlock -nas" and see if any of those work.

  • by Anonymous Coward on Wednesday January 28, 2015 @01:04PM (#48924937)

    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

  • by nimbius ( 983462 ) on Wednesday January 28, 2015 @01:12PM (#48925025) Homepage
    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.
    • by smash ( 1351 )
      X11 no longer does one thing, and it certainly doesn't do it well. It needs to be refactored and split into smaller subsystems built with modern computing requirements in mind.
  • They want their lockscreen back.

    Come on, this is 2015!
    People nowadays think that typing into a CLI is low level hacking!
    Real men don't lock the screen anymore, they CTRL-ALT-Fn to the first available login prompt, go away, and CTRL ALT F7 back to their session when they return.

    Pussies!

  • Let this be a lesson to all of the architects out there who have a tendency to over-generalize, even to the point of abstracting away useful features.

  • Uh.

    Why can't I have my screen locker have a passive grab on Ctrl+Alt+Delete or shift+altgr+control+` or whatever, using XGrabKey. That way if someone else installs a screenlock faker then I'll know because it won't respond to the magic key presses.

    The thing is on Windows it never worked as well as it ought to. The reason is that if the screen said something like:

    "pls entar u r passwordz to login"
    [ password box ]
    [OK]

    "pls wate wile redirecting to http://scamsite.ru/yourbank [scamsite.ru]"

    "Pls entar u r bank passwrd thx"

    an

  • Xscreensaver (Score:5, Interesting)

    by gringer ( 252588 ) on Wednesday January 28, 2015 @02:52PM (#48926109)

    Jamie Zawinski has another explanation why screensavers on KDE [jwz.org] 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 [jwz.org], discussing why locking and unlocking is a hard problem, especially when accessibility features are required.

  • by davek ( 18465 ) on Wednesday January 28, 2015 @04:22PM (#48926923) Homepage Journal

    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.

"For a male and female to live continuously together is... biologically speaking, an extremely unnatural condition." -- Robert Briffault

Working...