Bug 1034031 - Login screen gets stuck somehow after accessing an active session using 'Switch user', next time you use 'switch user' function, last accessed session's password can be exposed
Summary: Login screen gets stuck somehow after accessing an active session using 'Swit...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-shell
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F20FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2013-11-25 06:16 UTC by James Patterson
Modified: 2013-12-22 02:33 UTC (History)
14 users (show)

Fixed In Version: gnome-shell-3.10.2.1-2.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-11-29 13:57:43 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
GNOME Bugzilla 710456 None None None Never

Description James Patterson 2013-11-25 06:16:11 UTC
Description of problem:
You can reveal the password of a logged in gnome user by switching users.

Version-Release number of selected component (if applicable):


How reproducible:
gdm-3.10.0.1-1.fc20.x86_64

Steps to Reproduce:
1. Login as user X
2. Go to switch user
3. Login as user X
4. Go to switch user
5. See password masked in password field
6. Go to options, show text

Actual results:
See user's password.


Expected results:
Do not see user's password.


Additional info:
I tried this three times, could reproduce it three times.

Please mark as security bug and blocker if you can reproduce.

Comment 1 James Patterson 2013-11-25 14:00:57 UTC
Note: a second user is required even though the steps above never use it.

I can reproduce this bug reliably on multiple computers.

Adding Red Hat person to CC since this bug is quite serious.

Comment 2 Adam Williamson 2013-11-25 17:15:37 UTC
Proposing as a final blocker: https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Security_bugs -

"The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation)."

this could be resolved with an update, I guess, but it looks like a pretty bad issue and could hit people who install from static media before they update.

Comment 3 Vincent Danen 2013-11-25 17:43:11 UTC
I don't have a Fedora 20 system to test this on, but I tried on Fedora 19 and it doesn't work.  But I just want to verify something first to see if I understand this correctly.

You have a system with user A and user B on it.  User A logs into his desktop and hits "switch user".  User A logs in as user A again (user A obviously knows his own password as he's now logged in twice with his password).

User A again goes to "switch user" and back at gdm sees a bunch of dots representing his password in the password field.  User A select options, show text, and he sees his own password, which he entered in twice already to get to this point.

Is that correct?

So user A is able to view his _own_ password.  He's not able to view user B's password this way (unless he already knows it, as he needs to actually login as user B first), correct?

I suppose this is bad if someone is shoulder surfing, but would this not be a case of "don't do that"?  I mean, if you do this and see a bunch of dots in your own password field and you're asking to see the contents of it... isn't the computer doing what you've told it to do?  How is this unexpected?

I think this is a bug that should be fixed, but I don't see a trust boundary being crossed so I'm not sure that this is an actual security _flaw_.

Comment 4 James Patterson 2013-11-25 19:26:00 UTC
> Is that correct?

Yes, but one important point: user B cannot also switch user and reveal user A's password.

Comment 5 James Patterson 2013-11-25 19:27:38 UTC
So some more information after some playing around: the login screen gets stuck. When it gets stuck, you can hit ESC and it goes back to the chooser. If you don't hit ESC you can reveal the password of whichever user it got stuck on.

Comment 6 Vincent Danen 2013-11-25 21:32:02 UTC
I don't know what "gets stuck" means.  When it's stuck in this manner, does it happen right away?  I mean, if user A is switching to another user, is he going to notice it gets stuck, or is user switching an acceptable way of locking your screen to go grab a coffee?

There are two different commands, unless things changed in Fedora 20: lock screen and switch user.  Is it reasonable to assume that a person who wants to lock the screen will use "switch user" when "lock screen" is right there?

Or, alternatively, is it reasonable to assume that if user A is going to give the computer to user B (and they are physically separate people) that he would not wait until user B is logged in before wandering off, and so would thus know that it "got stuck"?

I guess I'm having a hard time still seeing where a trust boundary is crossed.  I certainly believe this is a bug to fix, but I'm not convinced it's a security bug.

Comment 7 Adam Williamson 2013-11-25 21:33:48 UTC
vdanen: to be clear, I didn't really look at this closely before throwing it on the proposed blocker list, and so far your evaluation of the (lack of) security impact seems reasonable.

Comment 8 Vincent Danen 2013-11-25 21:48:37 UTC
Yeah, I hadn't thought you looked too closely at it, but that's not a big deal.  It's certainly something that sounds bad, but I don't think that it is and I don't necessarily think it needs to be removed from the F20 blocker list, I just don't think it needs the whole CVE song-and-dance.

Comment 9 James Patterson 2013-11-25 22:07:17 UTC
> I don't know what "gets stuck" means.

From above:

1. Login as user X
2. Go to switch user
3. Login as user X
4. Go to switch user
5. See password masked in password field <--- HERE

At the point marked HERE, the gdm login screen is stuck: normally gdm hands off onto a gnome session and gdm clears or does whatever it does. In this case gdm hands off onto a gnome session but doesn't clear. When you switch back, gdm is showing a spinner and has a revealable password in the password field.

The above example is taken from a session where only one user is logged in, but multiple users exist on the system, but as per comment 5 I can also see the password of a user that is not me.

> I certainly believe this is a bug to fix, but I'm not convinced it's a security bug.

It's a password being revealed. Not only that, the password reveal can happen to another user. If revealing a password in plaintext is not a security bug, then I give up.

Were you able to play around with this to reproduce it?

Comment 10 Adam Williamson 2013-11-25 22:33:46 UTC
James: the operative question is _to whom_ the password is being revealed. You say "the password reveal can happen to another user" but I don't really immediately see how. How exactly could a 'user Y' exploit this problem to see user X's password? The only way I can see is if user X does switch user and then re-logs in as himself then leaves things in that state for user Y to come along and go to 'switch user'. OK, in that case Y can possibly see X's password, but it seems like a pretty unusual case, and there's no real way Y can 'trigger' it: it relies on X doing something fundamentally pointless ('switching user' to herself).

Comment 11 James Patterson 2013-11-25 22:43:52 UTC
I'm not sure I agree: a normal computer user isn't going to click "switch user", then think "oh that looks a bit odd, I'll stand here for a moment and see what happens, oh wait now I see a masked password field, let me see if there is a way of unmasking it, oh yes there is a way of doing that too, good thing I stopped to check this before handing my computer over to sneaky steven!".

Still, I'll try and reproduce the reveal of another user's password and report back.

Comment 12 Adam Williamson 2013-11-25 22:50:42 UTC
James: that's not the point of your reproduction process I'm querying. It's 2. and 3. that are the sticking point. As you wrote it, User X needs to login _and then hit 'switch user' and log in as himself again_ before the bug happens. That's a step that doesn't make much sense. Will someone somewhere do it at some point? Probably. But is it common enough to make this a major security issue? Doubtful.

(Vincent and I can both reproduce the bug, that's not at issue.)

Comment 13 Adam Williamson 2013-11-25 22:58:56 UTC
I can reproduce the issue by doing this, with users 'test' and 'test2':

* Log in as 'test'
* Switch user to 'test2'
* Switch user to 'test'
* Lock 'test's screen
* From the unlock dialog, hit "Log in as a different user"

At that point, I can expose 'test's password.

This does indeed make it sound like a serious security issue, because that's a sensible series of actions where a trust boundary is crossed. In the 'real world', two people have access to a PC, and use the 'switch user' function. After switch user has been used a couple of times and they're both logged in, if either of them locks the screen and walks away, the other (or anyone else) can come by, hit 'Log in as a different user', and expose their password.

It seems like the basic bug here is that the login screen gets confused after using the 'switch user' interface to re-access a running session (as opposed to starting a new session), and when you go back to the 'switch user' interface, it's stuck in the messed-up state, which happens to allow you to expose the password of the user whose session it last accessed.

Comment 14 James Patterson 2013-11-25 23:08:31 UTC
But surely the login screen getting stuck is subject to tons of different ways of taking advantage.

Here is another:

Login as user1
Lock screen

Click login as another user
Login as user2
Lock screen

Cycle through the virtual terminals
Find user1’s vt on pts/7
Click show text to view their password

Comment 15 Fedora Update System 2013-11-26 04:07:03 UTC
gnome-shell-3.10.2.1-2.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/gnome-shell-3.10.2.1-2.fc20

Comment 16 James Patterson 2013-11-26 14:27:25 UTC
Seems to work for me, but I will test more tonight. I added karma to the release.

Thanks!

Comment 17 Fedora Update System 2013-11-26 18:02:06 UTC
Package gnome-shell-3.10.2.1-2.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing gnome-shell-3.10.2.1-2.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-22168/gnome-shell-3.10.2.1-2.fc20
then log in and leave karma (feedback).

Comment 18 Mike Ruckman 2013-11-26 18:09:50 UTC
+1 Blocker

Comment 19 Jóhann B. Guðmundsson 2013-11-26 18:38:03 UTC
+1 Blocker

Comment 20 Adam Williamson 2013-11-26 18:42:27 UTC
Setting AcceptedBlocker with three votes, thanks.

Comment 21 Kamil Páral 2013-11-27 13:15:42 UTC
With gnome-shell-3.10.2.1-2.fc20 I was no longer able to reproduce any of the issues described here. However, it was quite easy to make gnome-shell consume 100% cpu and only show black screen after a few rounds of user switching (which might not be a recent regression, however). I'll report that separately.

Comment 22 Kamil Páral 2013-11-27 13:39:29 UTC
(In reply to Kamil Páral from comment #21)
> I'll report that separately.

https://bugzilla.gnome.org/show_bug.cgi?id=719418

Comment 23 Peter Weber 2013-11-27 14:59:15 UTC
Does anyone informed upstream GNOME about this issue? Is their a bug?

Comment 24 Florian Müllner 2013-11-27 18:01:55 UTC
(In reply to Peter Weber from comment #23)
> Does anyone informed upstream GNOME about this issue?

Yes, both this issue (see "External Trackers" above) and the memory consumption issue from comment #22 have been reported upstream.

Comment 25 Peter Weber 2013-11-27 21:03:43 UTC
Thanks! I've overseen the table with external bugtrackers.

Comment 26 Fedora Update System 2013-11-29 13:57:43 UTC
gnome-shell-3.10.2.1-2.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 27 gatlibs 2013-12-17 20:12:00 UTC
I still have this issue.

Has any one else had success, besides James Patterson?
I have been running F20 since Alpha.
I am using the following shell:
Name        : gnome-shell
Arch        : x86_64
Version     : 3.10.2.1
Release     : 3.fc20

Comment 28 Adam Williamson 2013-12-17 20:18:29 UTC
gatlibs: what do you mean by 'this issue', precisely?

Comment 29 gatlibs 2013-12-22 02:33:07 UTC
I retested and did not have this issue. I must have updated after or not restarted. I do not have this issue any longer.


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