Bug 697199

Reproducible: every time.

Switch user then use ctrl+alt+fN to switch back to the original user. The screensaver is not activated.

Security hole -> please up severity.

Hello,

  thank you for your report.

(In reply to comment #1)
> Reproducible: every time.
> 
> Switch user then use ctrl+alt+fN to switch back to the original user. The
> screensaver is not activated.
> 
> Security hole -> please up severity.

By any chance have you reported this issue upstream:?
[1] https://bugzilla.gnome.org/enter_bug.cgi?product=gnome-desktop

Have searched the currently opened gnome-desktop upstream bugzilla
entries, and could not find one for this issue.

Please provide a link if you already filed one. Otherwise I will
file a new one and contact the upstream developers.

Thank you, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team

Hello,

No I haven't filed this upstream. Thanks.

Upstream bug report:
[2] https://bugzilla.gnome.org/show_bug.cgi?id=648234

Low impact?

According to the Classification of Security Issues documented here:
 https://access.redhat.com/security/updates/classification/

This is an Important impact bug.

"This rating is given to flaws that can easily compromise the confidentiality, integrity, or availability of resources. These are the types of vulnerabilities that allow local users to gain privileges, allow unauthenticated remote users to view resources that should otherwise be protected by authentication, allow authenticated remote users to execute arbitrary code, or allow local or remote users to cause a denial of service."

(In reply to comment #5)
> Low impact?
> 
> According to the Classification of Security Issues documented here:
>  https://access.redhat.com/security/updates/classification/
> 
> This is an Important impact bug.
> 
> "This rating is given to flaws that can easily compromise the confidentiality,
> integrity, or availability of resources. These are the types of vulnerabilities 
> that allow local users to gain privileges..

Low / moderate impact due the fact:
1) the attacker needs to be locally proximate,
2) successful exploitation of this would require the victim
   not to log out themselves via normal logout process but
   rather rely on screensaver / switch user screen to perform
   the log out for them automatically (which is pretty unlikely
   scenario, but possible).

Though we may revisit the classification of the severity of this
issue. Just let us know, why do you think this should be of
higher security impact.

Thanks && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team

CVE Request:
[3] http://www.openwall.com/lists/oss-security/2011/04/19/4

Hm... Fedora is by default exploitable in the environment this feature is designed for, i.e. a multi-user environment.

(In reply to comment #6)
> Low / moderate impact due the fact:
> 1) the attacker needs to be locally proximate,

To quote "Important impact":
 "These are the types of vulnerabilities that allow local users to gain privileges,"

To take an extreme example: to gain privileges you poison the user's bin directory/bash startup scripts/gnome-session programs, etc.

But more important are "flaws that can easily compromise the confidentiality, integrity, or availability of resources" (as mentioned before).

> 2) successful exploitation of this would require the victim
>    not to log out themselves via normal logout process but
>    rather rely on screensaver / switch user screen to perform
>    the log out for them automatically (which is pretty unlikely
>    scenario, but possible).

This is not unlikely? Switch user is designed for this scenario.!

> Though we may revisit the classification of the severity of this
> issue. Just let us know, why do you think this should be of
> higher security impact.

Ok. If you want I can post to fedora-devel?

(In reply to comment #8)
> > Though we may revisit the classification of the severity of this
> > issue. Just let us know, why do you think this should be of
> > higher security impact.
> 
> Ok. If you want I can post to fedora-devel?

Please use the email address of Red Hat Security Response Team,
secalert for this purpose.

Thanks && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team

The CVE identifier of CVE-2011-1596 has been assigned to this issue.

Note: although gnome-screensaver crashes, I cannot reproduce the "screen left unlocked" part.

I can reliably crash gnome-screensaver as follows:

1. user1: from top-right username dropdown, choose "lock screen"
2. user1: choose "switch user"
3. login as user2
4. user2: from top-right username dropdown, choose "lock screen"
5. user2: choose "switch user"
6. login as user2
7. user2: notice abrt icon in hidden status bar, and notification that gnome-screensaver has crashed.

trace sent to JL.

> trace sent to JL.

JL?

Can you enclose the backtrace either on this bug or the upstream bug please?

Created attachment 494843 [details]
Backtrace provided by the reporter

(In reply to comment #12)
> > trace sent to JL.
> 
> JL?

Me was meant under abbreviation of JL.

> 
> Can you enclose the backtrace either on this bug or the upstream bug please?

Attached in previous comment.

Hello,

  thank you for the detailed scenario below.

(In reply to comment #11)
> Note: although gnome-screensaver crashes, I cannot reproduce the "screen left
> unlocked" part.
> 
> I can reliably crash gnome-screensaver as follows:
> 
> 1. user1: from top-right username dropdown, choose "lock screen"
> 2. user1: choose "switch user"
> 3. login as user2
> 4. user2: from top-right username dropdown, choose "lock screen"
> 5. user2: choose "switch user"
> 6. login as user2
> 7. user2: notice abrt icon in hidden status bar, and notification that
> gnome-screensaver has crashed.
> 
> trace sent to JL.

How "then use ctrl+alt+fN to switch back to the original user." from
https://bugzilla.redhat.com/show_bug.cgi?id=697199#c1 fits into this
new scenario? (into which step)

So the original issue description:
"If I switch users the original user's screen is not locked."
was intended to say:
..
6. login as user2
7. user2: notice abrt icon in hidden status bar, and notification that
   gnome-screensaver has crashed.

IOW / in short version, there is no 'user's screen is not locked'
symptome anymore (was it present originally?) and the 'only' impact
is screensaver crash?

Thank you, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team

Hi,
From the crash report attached on this bug, it seems like the crash is only in gnome-screensaver-dialog and does not cause the daemon to crash.

Are you still able to reproduce this issue ?

I can no longer reproduce the bug as originally reported.

I suspect two things:
1. A system package was updated while I was logged in that caused gnome-screensaver to fail to lock
or:
2. gnome screensaver recovers more gracefully than it did

So if you want you can close this bug since this bug is specific to the security issue, and I can reopen it later if it happens again (but g-s still crashes for me).

(In reply to comment #17)

> So if you want you can close this bug since this bug is specific to the
> security issue, and I can reopen it later if it happens again (but g-s still
> crashes for me).

Regarding the crash, can you please try the latest version of gnome-screensaver from the gnome git, the following patch should resolve your crash.


commit 338b86c4f0c2cdc4241dbf5cda913f0184afc105
Author: Huzaifa Sidhpurwala <huzaifas>
Date:   Tue Apr 26 13:15:56 2011 -0400

    dialog: Fix crash in user switcher code
    
    The user switch button currently causes the lock dialog to crash
    because of an inverted conditional in the error checking code.
    
    This commit addresses the crash by performing the proper check
    in the conditional.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=648234

Sure, can you push the change to updates-testing for F15?

I can actually do a quick scratch build for you, if you want

That would be great.

Scratch build here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3029265

Please let me know if this helps.

WFM - thanks!

Further investigation has revealed the problem described in this
bug report is just a crash in the gnome-screensaver-dialog, and
does not cause the screensaver itself to be killed.

Red Hat does not consider this bug to be a security issue.

I've just had this happen again - twice.

Using the method in comment #1.

Reopening.

When gnome-shell for user 2 crashes (bug 725187), you can often but not always simply ctrl+fN to get to the user 1's screen.

This surely cannot happen if gnome-screensaver is checking whether the screensaver was successfully activated before switching users.


Why this bug is important

This bug severely limits the effectiveness of a user to safeguard their data.
They reasonably expect that their workstation is locked when they switch users. It isn't always.

This bug is less reproducable now, but I still see it four to five times per day.

I've also seen gnome-screensaver crash reports and been able to switch users without passwords (on F15). Next time it happens I'll see if I can get a backtrace.

Although I've been waving a big red security flag around for four months now, nobody seems to actually care.

@Red Hat: there is zero point having SELinux if we fail at the most basic level to prevent a screen lock from working.

Bug 725187 has strack traces if you want them.

This bug is also reproducable in Fedora 16 (x86)

+1 comment#29 :')

also

similar bugs for duplicate consideration:

  https://bugzilla.redhat.com/show_bug.cgi?id=677345
  https://bugzilla.redhat.com/show_bug.cgi?id=682132
  https://bugzilla.redhat.com/show_bug.cgi?id=713640
  https://bugzilla.redhat.com/show_bug.cgi?id=714784
  https://bugzilla.redhat.com/show_bug.cgi?id=748560
  https://bugzilla.redhat.com/show_bug.cgi?id=761074

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

Closing bug due to lack of interest from Red Hat.