Bug 1030431 (CVE-2013-7220)

The Alt+F2 dialogue doesn't come from gnome-settings-daemon.

(In reply to Bastien Nocera from comment #1)
> The Alt+F2 dialogue doesn't come from gnome-settings-daemon.

The bug is not related to the Alt+F2 dialog box, but with the lock screen function itself.

(In reply to Ratul Gupta from comment #2)
> (In reply to Bastien Nocera from comment #1)
> > The Alt+F2 dialogue doesn't come from gnome-settings-daemon.
> 
> The bug is not related to the Alt+F2 dialog box, but with the lock screen
> function itself.

The lock screen also doesn't live in gnome-settings-daemon. Which part of gnome-settings-daemon do you think might be at fault here?

I also couldn't reproduce this on F20.

(In reply to Bastien Nocera from comment #3)
> (In reply to Ratul Gupta from comment #2)
> > (In reply to Bastien Nocera from comment #1)
> > > The Alt+F2 dialogue doesn't come from gnome-settings-daemon.
> > 
> > The bug is not related to the Alt+F2 dialog box, but with the lock screen
> > function itself.
> 
> The lock screen also doesn't live in gnome-settings-daemon. Which part of
> gnome-settings-daemon do you think might be at fault here?

See bug #1024786 for the original report.  There are a few moving parts here -- it could be the lock screen functionality, it could be the search functionality in some way.  I can't say whether or not gnome-settings-daemon is incorrect or not; if you have a better suggestion of the component this may belong to, please feel free to advise.  We're not the GNOME experts and only have a (reproducable) bug to go on.
 
> I also couldn't reproduce this on F20.

So?  Fedora 18 and 19 are both still supported and should be looked at to see what the cause is and what probably fixed it for F20 (and whether that can be applied to F18/F19 to fix it there as well).

Taking another look at this, gnome-screensaver is probably _not_ the culprit as it is the same version on Fedora 18, 19, and 20 (3.6.1), unless it is due to an interaction with some other library that may have a different version between Fedora 19 and 20.

Unfortunately I don't have time to look into this further, but perhaps bringing this up with upstream and seeing if it affects GNOME3 on other platforms, would be a wise way of tracking the problem down.  Or maybe Ratul can bring this up on the oss-sec mailing list as well (in particular of F20 is no longer affected, upstream may no longer be affected also, if it ever was).

(In reply to Vincent Danen from comment #5)
> Taking another look at this, gnome-screensaver is probably _not_ the culprit
> as it is the same version on Fedora 18, 19, and 20 (3.6.1), unless it is due
> to an interaction with some other library that may have a different version
> between Fedora 19 and 20.

gnome-screensaver is unused in GNOME sessions in F19 and F20.

> Unfortunately I don't have time to look into this further, but perhaps
> bringing this up with upstream

I'm the gnome-settings-daemon maintainer upstream. I'll reassign this to gnome-shell where the Alt+F2 dialogue and the screensaver are implemented.

> and seeing if it affects GNOME3 on other
> platforms, would be a wise way of tracking the problem down.  Or maybe Ratul
> can bring this up on the oss-sec mailing list as well (in particular of F20
> is no longer affected, upstream may no longer be affected also, if it ever
> was).

Some more details on how to reproduce the problem would certainly be helpful. What sort of session was this running? Do you have a video showing the problem?

Assuming that the issue is triggered by leaving the run dialog open when locking the screen, this was fixed upstream in https://bugzilla.gnome.org/show_bug.cgi?id=708218, which should be easy to backport.
Or is there a way to trigger the run dialog itself from the lock screen? In that case, the session log would probably provide useful pointers to the cause of the bug.

Bug 1024786 describe another vector using search in the activity screen (that's the "blind" part) that may have been fixed earlier.

Looking at the fix, is there really no proper way to implement screen locking other than building list of dialogs that may need closing?

(In reply to Tomas Hoger from comment #10)
> Bug 1024786 describe another vector using search in the activity screen
> (that's the "blind" part) that may have been fixed earlier.

Since at least GNOME 3.8 (F19) locking the screen will fail if we cannot get a keyboard grab; this should make this situation impossible. More so, typing away at the lock screen will now trigger the unlock dialog (and redirect input to the password field).

So I very much doubt that this can be reproduced on newer versions.


> Looking at the fix, is there really no proper way to implement screen
> locking other than building list of dialogs that may need closing?

Alternatively we could make sure that screen shield and unlock dialog are stacked above system dialogs, but then we'd need to special-case system dialogs that actually may show in a locked environment (for instance when asking for polkit authentication when a shutdown is requested from the login screen while other users have open sessions).

Acknowledgement:

Red Hat would like to thank M.Schwarz of resellerdesktop.de for reporting this issue.

(In reply to Florian Müllner from comment #11)
> Since at least GNOME 3.8 (F19) locking the screen will fail if we cannot get
> a keyboard grab; this should make this situation impossible. More so, typing
> away at the lock screen will now trigger the unlock dialog (and redirect
> input to the password field).

Do you possibly have a reference (bug and/or commit) for that change handy?

(In reply to Tomas Hoger from comment #13)
> Do you possibly have a reference (bug and/or commit) for that change handy?

Sure, https://bugzilla.gnome.org/show_bug.cgi?id=686740.

(In reply to Florian Müllner from comment #15)
> Sure, https://bugzilla.gnome.org/show_bug.cgi?id=686740.

I assume that bug is for:

> More so, typing away at the lock screen will now trigger the unlock dialog
> (and redirect input to the password field).

I though this is the real reason 3.8 is no longer affected:

> Since at least GNOME 3.8 (F19) locking the screen will fail if we cannot get
> a keyboard grab; this should make this situation impossible.

There are two distinct issues which are reported in the bug:

1. blind command execution via activities search keyboard focus
2. run command dialog visible above screen locker

Therefore it makes sense to split this bug into two parts. We will be using this bug for the first issue.

Description:
The issue is that in Fedora 18, when you open either the Activities panel or "Enter a command" dialog box (Alt+F2), and then lock the screen or let the screensaver lock the screen, then if you start typing on the lock screen, instead of entering the password or just waking the screen, it actually types anything you type on the Activities panel or "Enter a command" dialog box, so anyone who enters a executable command and press enter, the command is executed even when the screen is locked.

(In reply to Huzaifa S. Sidhpurwala from comment #18)

> 2. run command dialog visible above screen locker

This issue is filed under:

https://bugzilla.redhat.com/show_bug.cgi?id=1046839

This issue was resolved (as mentioned in comment #11) by slightly changing the behaviour of gnome-shell with respect to how keystrokes are handled when the screensaver is on.

More details are available at:
https://bugzilla.gnome.org/show_bug.cgi?id=686740

And a series of commits fix this issue via:

https://git.gnome.org/browse/gnome-shell/log/js/ui/screenShield.js?qt=grep&q=686740

This issue was addressed in upstream release of gnome-shell-3.7.92

This issue does not affect the version of gnome-shell as shipped with Fedora-19 and Fedora-20.

This issue has been assigned CVE-2013-7220 as per:

http://www.openwall.com/lists/oss-security/2013/12/27/8