Bug 1030431 - (CVE-2013-7220) CVE-2013-7220 gnome-shell: blind command execution via activities search keyboard focus
CVE-2013-7220 gnome-shell: blind command execution via activities search keyb...
Status: CLOSED NOTABUG
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20131114,repor...
: Security
Depends On: 1024786 1031926
Blocks: 1030960
  Show dependency treegraph
 
Reported: 2013-11-14 07:41 EST by Ratul Gupta
Modified: 2015-08-19 04:19 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-27 21:45:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Ratul Gupta 2013-11-14 07:41:34 EST
Fedora 18 is found to be vulnerable to the blind command execution on the lock screen, and Fedora 19 is found to execute command through "Enter the Command" dialog box at the lock screen.

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 Fedora 19, the "Enter the Command" dialog box is visible even after you lock the screen, so anyone can write the commands in the box and execute them over a locked screen.

The issue is still to be fixed and tested on Gnome Fedora 18 and 19 machines. KDE version were not found to be affected.
Comment 1 Bastien Nocera 2013-11-14 07:44:43 EST
The Alt+F2 dialogue doesn't come from gnome-settings-daemon.
Comment 2 Ratul Gupta 2013-11-14 08:09:14 EST
(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.
Comment 3 Bastien Nocera 2013-11-14 10:03:18 EST
(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.
Comment 4 Vincent Danen 2013-11-14 14:25:21 EST
(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).
Comment 5 Vincent Danen 2013-11-14 14:32:52 EST
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).
Comment 7 Bastien Nocera 2013-11-14 16:34:36 EST
(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?
Comment 9 Florian Müllner 2013-11-15 08:07:53 EST
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.
Comment 10 Tomas Hoger 2013-11-15 08:56:38 EST
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?
Comment 11 Florian Müllner 2013-11-15 11:50:24 EST
(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).
Comment 12 Ratul Gupta 2013-11-18 07:28:00 EST
Acknowledgement:

Red Hat would like to thank M.Schwarz of resellerdesktop.de for reporting this issue.
Comment 13 Tomas Hoger 2013-11-18 07:47:41 EST
(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?
Comment 15 Florian Müllner 2013-11-18 10:32:43 EST
(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.
Comment 16 Tomas Hoger 2013-11-18 11:01:54 EST
(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.
Comment 18 Huzaifa S. Sidhpurwala 2013-12-26 23:52:32 EST
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.
Comment 19 Huzaifa S. Sidhpurwala 2013-12-27 00:09:30 EST
(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
Comment 20 Huzaifa S. Sidhpurwala 2013-12-27 00:43:17 EST
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.
Comment 21 Huzaifa S. Sidhpurwala 2013-12-27 21:45:46 EST
This issue has been assigned CVE-2013-7220 as per:

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

Note You need to log in before you can comment on or make changes to this bug.