The awful thing about getting it right the first time is that nobody realizes how hard it was.

Ubuntu security problem in the lock screen

I am running Ubuntu 14.04 with all the packages updated. When the screen is locked with password, if I hold ENTER after some seconds the screen freezes and the lock screen crashes. After that I have the computer fully unlocked.

You're using gnome-screensaver? Do you want ants? Because that's how you get ants.

I told you so, 2004 edition.

I told you so, 2005 edition.

Previously, previously, previously.


Update:

I've seen a few comments elsewhere about this saying things like, "So what, it was a bug, they've fixed it." That's really missing the point. The point is not that such a bug existed, but that such a bug was even possible. The real bug here is that the design of the system even permits this class of bug. It is unconscionable that someone designing a critical piece of security infrastructure would design the system in such a way that it does not fail safe.

Especially when I have given them 2+ decades of prior art demonstrating how to do it right, and a decade-old document clearly explaining What Not To Do that coincidentally used this very bug as it's illustrative strawman!

You must be this tall to work on security infrastructure. If you don't think this bug was a shameful embarrassment of design -- as opposed to merely bad code -- then please get out of the software industry.

Tags: , , , ,

37 Responses:

  1. mhoye says:

    Hi there, my name is Dug, and many eyes make bugs SQUIRREL!

    Hi there.

  2. cryptomail says:

    How does it feel to be continuously right? It must feel good, and yet sad :(

  3. gryazi says:

    I guess this solves the problem of giving users random passwords and then being asked to walk over and fix whatever's wrong on their auto-locked screens.

  4. Gunnar says:

    It is not gnome-screensaver. It is a new screensaver integrated in Unity.

  5. DaveL says:

    Unity is the thing that makes me hate Ubuntu.

  6. jpatokal says:

    Could it be worse? Why, yes, it could be.

    "Why doesn't my screen lock when I'm logged in as root?

    gnome-screensaver will blank the screen but will not lock. This is for security reasons. Seriously, it is very unwise to login as root in the first place. Try logging in as an unprivileged user and using sudo or su instead. "

  7. Jan says:

    I don't get it, possibly because I don't know in detail how graphical output is managed under Linux. Why isn't such a basic and critical functionality built into whatever makes windows appear on the monitor? Implement a "locked" mode, which makes it stop making the windows appear on the monitor (and passing keystrokes into them), and instead makes it make other windows appear on the monitor and pass the keystrokes to them. The other window(s) being some kind of "login" process that has the ability to verify passwords and send an unlock command.

    If someone manages to crash the login process, well, too bad, no unlock command for you. If someone manages to crash the main process, well, too bad, no graphical output for you. I understand how a program that just "covers up" the screen (releasing it when crashed) could be built and used as decades ago because it was the easiest solution, but (no offense intended) I cannot understand how such approach could be permanently kept.

    Can someone with more detailed knowledge please enlighten me why this is implemented the way it is? I assume there is a reason, but I would like to understand it.

    • jwz says:

      The short answer is that X11 is just ridiculously awful.

      The slightly longer answer is that there is no locking framework built into X per se. It's just another app, no different than any other, that has to bend over backwards to do system-level jobs as a user-level program.

      Part of this awfulness is that X11 is also incredibly old, and things that seemed like a good idea in the early 80s are now enshrined in its architecture to such a degree as to be unchangeable.

      • Christian Vogel says:

        Personally, I'm not appalled by the fact that someone wasted resources to re-invented the wheel, but I'm quite disappointed that they did it so poorly. And built the fourth broken implementation suffering from essentially the same class of bugs!

        You could even look at Windows, that finally got it right and runs Login/Lockscreen, Desktop-Session, the "really give administratives rights to this program"-dialog (and Services, and theoretically an unlimited amount of additional desktops) in well isolated "Desktops".

        So maybe one should just have copied that, disconnect all input devices from the currently running, and just run the fscking password prompt on a second X server?

    • jwz says:

      Not that OSX is any better in this respect: they made all the same mistakes and more. "ssh your-machine killall ScreenSaverEngine" will remotely unlock the screen on a logged-in-but-locked Mac.

      • Adolf Osborne says:

        Is that a bug, or a feature?

        I've killed screensavers remotely before...because I'm lazy, and I want to see what is going on with that machine over there from the keyboard that is over here.

        I don't know that I've succinctly as using a (presumably properly-authorized for that particular user) command line fed to ssh, but I'll bet that doing so has at least crossed my mind.

        In the UNIX way of things, as I understand it, each individual human has their own account(s), with root being very special (and/or deprecated).

        Maybe I'm overthinking it, but if local machine A is running a locked screensaver as me, why in the world would I not be able to kill/bypass the screensaver lock from remote machine B if I'm able to properly authenticate as me from there on machine A? Because after all, the authentication mechanism and credentials will be the same for A even if I access A from B, and I'm plainly me...so I should be able to do whatever the hell that I want with my processes -- including unlocking the console way-over-there (whether across the room, or on another continent).

        I count this as part of being network-transparent, which is always a boon. If it is a real problem, I submit that it ought to be dealt with in other ways (like, logging out/locking when you're done with a session).

        • Adolf Osborne says:

          which, upon a third review, is disjointed enough that I realize that I should sleep. Please disregard. (except: srsly. It's my screensaver process, and I can kill it in any way that I want to.)

          • jwz says:

            Well.... You know.... The whole Unix security model is basically "I'm sorry Sir, I didn't realize you were root."

            I don't think it's unreasonable to assume that when things have gotten into "type your password" mode that the typing of a password might actually be required.

            • Brad J says:

              Quick testing on 10.9 has the killall switching the screensaver over to the Computer Name module, but not unlocking the screen. Not sure if that's my work machine being hardened by my employer or a fix on Apple's part.

  8. mirabilos says:

    Ah well, you say to use xscreensaver instead
    of whatever one is currently using… but I’m
    using xlock, and xscreensaver is not a drop-in.
    I admit I do not understand xscreensaver, but
    it looks to me like it wants to run a dæmon,
    stays around in memory, and there is no simple
    equivalent to calling 'xlock -mode random',
    'xlock -mode life', 'xlock -mode cage', and
    'xlock -mode blank' (the latter to save CPU
    and GPU on systems running BOINC).

    I really want a (one) executable I call to
    lock my XFree86® session, which ends when
    I terminate it.

    • jwz says:

      Then it sounds like xlock is what you want. Go with God.

    • Unfortunately, since xlock had no upstream after Patrick Naughton moved on to developing Java, I don't know if any of the other copies of xlock ever got the fix for Sun Bug 1077337 - xlock crashes when handling many return keypresses leaving system open from 1993.

      Of course, if you're still actually running XFree86, you've got more than enough security bugs already that one more won't matter, and can probably have your screen unlocked already by the grab killing keystrokes.

      • jwz says:

        Wow, it's almost like you're trying to argue with a dinosaur who said "my list of requirements is the exact list of features provided by a program last updated in 1989 and nothing else will do". Whereas, my response was "that 1989 release of that program still exists; vaya con dios". (In 1998 I still cared enough to say this using more words.)

  9. They fixed this bug before making a release.

    Hilariously, they missed this other bug.

  10. eventually says:

    be sure to read to the end.

    • bobo the hobo says:

      The end? Where someone claims the problem was "fixed" before shipping? Be sure to read the update at the top of this thread where it is carefully and correctly explained at you that anyone who believes patching a symptom of gross architectural malfeasance to be a "fix" is, in reality, a moron who has no business writing software. At all.

  11. eventually says:

    i am very sorry. i clicked the wrong reply button. i meant the end of this other bug: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1313885

  12. Julian says:

    I am always right too. I am sick and tired of people making mistakes that are just so obvious to people like us with superior bug recognition and detection capabilities.

    • Nate says:

      It's funny, because this is not about superior bug recognition or detection. This is about not loading both barrels of a gun and jerking it repeatedly towards your foot.

      Bugs can appear from design, architecture, or coding mistakes. Seeing that a major design choice (larding up your unlock process with random libraries) would result in myriad potential bugs in the later architecture/coding choices is what should have happened.

      Try working on the high wire some day where a bug costs you or your company millions of dollars or, worse, kills someone. Wait, don't do that until you have the necessary pervasive sense of fear of what it takes to work on the high wire.

  13. This made the rounds at my work today:
    http://gizmodo.com/programming-sucks-why-a-job-in-coding-is-absolute-hell-1570227192
    PS. I'm bailing on Science for software. The world is cruel.