Ubuntu 14.04: security problem in the lock screen

[Marco Agnese]

affects ubuntu

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

--
Marco Agnese

This bug is about the lockscreen being bypassed when unity crashes/restarts, which is a critcal security issue. The crash will be handled from bug 1308750

[Brian Murray (brian-murray)]

I've recreated this and after holding the enter key for quite some time my screen was unlocked. I noticed the following in /var/log/syslog:

Apr 16 12:41:14 blacklightning gnome-session[2708]: WARNING: Application 'compiz.desktop' killed by signal 6
Apr 16 12:41:14 blacklightning gnome-session[2708]: WARNING: App 'compiz.desktop' respawning too quickly
Apr 16 12:41:14 blacklightning gnome-session[2708]: CRITICAL: We failed, but the fail whale is dead. Sorry....

[Brian Murray (brian-murray)]

/var/log/auth.log indicates quite some time is about 30 seconds so not that long.

[Adam Conrad (adconrad)]

14:13 < infinity> jdstrand: If you're hunting down people to poke about this, can you (strongly) suggest that this needs two fixes? First, obviously it shouldn't crash, but second, a restart-post-crash of unity should *always* start locked.
14:13 < infinity> jdstrand: Since there's no way to 100% be sure you know the previous state, one can only assume a rexec may need to be locked, and may becomes must because of the uncertainty.

[Jamie Strandboge (jdstrand)]

This probably needs two fixes: fix the crasher and making sure a restart of unity after a crash is locked.

[Adam Conrad (adconrad)]

To be clear, the "always restart locked" half of the fix is the more important bit. The crash is embarrassing, but crashes will happen, and we'll find others. Having it restart unlocked is bordering on unforgivable, and we should focus on fixing that first.

[Robert Bruce Park (robru)]

So both the linked branches built in silo 8, and when I tested it, this is what I found:

1. start unity

2. open terminal (Ctrl+alt+T)

3. type 'sleep 15 && killall -9 compiz'

4. lock screen

observe: screen locks, then unity crashes, then unity restarts locked. so far so good.

5. issue the same command in the terminal again

6. lock the screen again

observe: screen locks, then unity crashes... and doesn't come back.

I'm told this is not a regression (eg it's known that unity does not restart after the first crash) however this is significant because when unity does not restart, that terminal just stays open right there, and while it doesn't respond to keyboard input, it does respond to mouse input, so it's possible to issue commands as the logged-in user by copy & pasting (eg, select some text, right click -> copy, right click -> paste).

So if I'm an attacker and I'm in a position to trigger a crash in compiz, the whole "restarting locked" thing seems kind of weak, because all I have to do is crash compiz... twice. Granted the unity-free UI is quite limited, maybe there's a browser open and I can access the user's email, or whatever. it's still an attack vector.

[Launchpad Janitor (janitor)]

This bug was fixed in the package unity - 7.2.0+14.04.20140416-0ubuntu1

---------------
unity (7.2.0+14.04.20140416-0ubuntu1) trusty; urgency=low

  [ Andrea Azzarone ]
  * Do not allow to activate twice the same entry! (LP: #1308572)

  [ Marco Trevisan (Treviño) ]
  * UnityScreen: save a locked.stamp file when locking/unlocking, to
    relock on startup This makes unity to relocks if it was locked
    before crashing... (LP: #1308572)
 -- Ubuntu daily release <email address hidden> Wed, 16 Apr 2014 22:41:19 +0000

[Marco Trevisan (Treviño) (3v1n0)]

robru: the fact that unity doesn't reload properly after some crashes it's related to to bug #1308800 (it seems upstart is not loading unity, so gnome-session is not reliable at all for this).

[xtsbdu3reyrbrmroezob (xtsbdu3reyrbrmroezob)]

This Lock Screen bug is just one of many unfixed security issues. Below is another long-standing issue that also allows one to bypass the lock screen...

https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/49579

[Seth (bugs-sehe)]

@kristian-erik-hermansen Cool find, but utterly irrelevant here. That bug is about users blindly trusting the screen to auto-lock (which they _should be able to_).

This bug is about the trust being broken even after they _verified_ that they had _explicitly_ locked their screens. That's (a) a very different issue (b) a very different severity of failure.

[Marc Deslauriers (mdeslaur)]

Yes, bug 49579 won't get fixed until we move away from xorg into Mir...

[Marco Trevisan (Treviño) (3v1n0)]

>
>
> > Yes, bug 49579 won't get fixed until
> we move away from xorg into Mir...

Well I thought the same, but it seems we still might get that fixed even
before ;-)

--
Treviño's World - Life and Linux
http://www.3v1n0.net

[Oliver Grawert (ogra)]

Just a sidenote: Unlike what the sensationalist article at heise.de from today suggests (which links here), this bug was fixed in a heroc effort over night *before* final release, the fix is on the 14.04 image that was released to end users.

[Peter Funk (pf-artcom-gmbh)]

Just another sidenote: I'm unaffected by this bug, because I always use xscreensaver instead of those newer unsecure rewrites.
People concerned about security might want to read the
http://www.jwz.org/blog/2014/04/the-awful-thing-about-getting-it-right-the-first-time-is-that-nobody-realizes-how-hard-it-was/
blog post of Jamie Zawinski who has written xscreensaver.