Bug 1034031

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.

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.

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_.

> Is that correct?

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

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.

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.

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.

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.

> 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?

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).

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.

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.)

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.

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

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

Seems to work for me, but I will test more tonight. I added karma to the release.

Thanks!

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).

+1 Blocker

+1 Blocker

Setting AcceptedBlocker with three votes, thanks.

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.

(In reply to Kamil Páral from comment #21)
> I'll report that separately.

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

Does anyone informed upstream GNOME about this issue? Is their a bug?

(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.

Thanks! I've overseen the table with external bugtrackers.

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.

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

gatlibs: what do you mean by 'this issue', precisely?

I retested and did not have this issue. I must have updated after or not restarted. I do not have this issue any longer.