Bug 592798 - Active file menu inhibits screensaver
Active file menu inhibits screensaver
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
12
All Linux
low Severity urgent
: ---
: ---
Assigned To: Peter Hutterer
Fedora Extras Quality Assurance
: Security, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-16 21:39 EDT by Keith G. Robertson-Turner
Modified: 2010-07-08 14:13 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-08 14:13:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 19946 None None None Never

  None (edit)
Description Keith G. Robertson-Turner 2010-05-16 21:39:05 EDT
Description of problem: I just reactivated a system locked with gnome-screensaver, and was given access to the Gnome desktop for about 10 seconds before it popped back to a password prompt. AFAIAC this is a security vulnerability, hence the urgent severity.

Version-Release number of selected component (if applicable):
gnome-screensaver-2.28.3-1.fc12.i686

How reproducible:
Unknown, it just happened, and I can't reproduce immediately.

Steps to Reproduce:
1. Allow timeout to activate screensaver
2. Reactivate system by moving mouse 
  
Actual results:
Immediate access to the desktop for about 10 seconds before password prompt.

Expected results:
Password prompt should precede access.

Additional info:
Not much I'm afraid, as system logs show nothing unusual. The active window was thunderbird-3.0.4-1.fc12.i686 with a file menu still open, if that's relevant. Only other active programs were firefox-3.5.9-2.fc12.i686 and bash-4.0.35-3.fc12.i686.

Not much to go on, sorry, but this definitely happened.

Will try to reproduce again.
Comment 1 Keith G. Robertson-Turner 2010-05-17 00:11:41 EDT
Confirmed that I can reproduce this every time.

Specific conditions are that an application file menu must be active, and this somehow interferes with gnome-screensaver's locking mechanism, allowing access to the desktop without entering a password, but then a delayed reaction causes the password prompt to appear too late.

If a bash prompt with root login is already open, then this would allow a local attacker unlimited access to a system presumed locked and safe by its owner. If not then at best the attacker would at least have unlimited access to the unprivileged user's home directory, with possible further access by exploitation of some other local privilege escalation attack vector.

+1 urgent review.
Comment 2 Carl G. 2010-05-21 10:26:03 EDT
Someone with the appropriate permission should set the security flag.
Comment 3 Ray Strode [halfline] 2010-05-21 10:27:19 EDT
We can't lock the screen when a menu is up.  This is a limitation of X unfortunately.

The screensaver should be activating if a menu is up either though...  Are you saying the screensaver pops up after the timeout when a menu is up?
Comment 4 Ray Strode [halfline] 2010-05-21 10:39:57 EDT
i meant

"The screensaver shouldn't be activating if a menu is up either though...  Are you
saying the screensaver pops up after the timeout when a menu is up? "
Comment 5 Tomas Mraz 2010-05-21 10:48:24 EDT
The power management switches off the display even when the menu is up. But the screensaver activates only when you move the mouse so the menu closes. I think the power management should not switch off the display if the screensaver cannot lock the screen properly at the same time.
Comment 6 Vincent Danen 2010-05-21 18:43:59 EDT
Has anyone been able to reproduce this on older versions, or is this specific to the version in Fedora 12?

I only have earlier versions of Fedora and Red Hat Enterprise Linux in virtual machines which don't lend themselves well to testing power management (FWIW, on RHEL5 having the menu open doesn't activate the screensaver, but can't test whether or not the screen gets blanked/monitor turns off).
Comment 7 Keith G. Robertson-Turner 2010-05-22 10:34:41 EDT
I can confirm that Comment 5 is the correct diagnosis.

Sequence:

1. Leave system idle with any file menu open
2. Screensaver fails to activate after preset timeout period
3. But power management successfully blanks the display (backlight off) after its separate preset timeout period
4. A user who may not have paid attention (me) then wrongly assumes the system is locked
5. User then reactivates system (ACPI/APM event), causing power management to unblank the display, presenting the desktop
6. User de-selects file menu, allowing screensaver to activate, which it then does immediately afterwards (thus causing some confusion)
7. Preset screensaver animation (if any) is briefly displayed, disappears, then is replaced by the screensaver password prompt
8. Only now is the system actually locked

This is broken behaviour, resulting in a security vulnerability. Although this vulnerability only occurs as a result of the user's misconception of the system's current state of security, that misconception is supported by the system's misleading responses and unexpected behaviour. Therefore this behaviour needs to be modified somehow. At the very least, point 6 (above) should not occur.

Please verify (from Comment 3) that this is in fact an Xorg bug, so it can be reassigned. E.g. does this also affect xscreensaver, or is this Gnome-specific?

Suggested resolution:

1. Open file menus should not inhibit the screensaver
2. If there is no way around that (currently), then if the screensaver is inhibited, power management display blanking should be also, to maintain consistency, avoid confusion, and prevent an unintentional security vulnerability

Currently needed:

1. Links to any relevant upstream bugs at Xorg regarding this issue
2. Test this condition with xscreensaver to confirm whether or not this is Gnome-specific
Comment 8 Luke Macken 2010-05-22 11:17:18 EDT
(In reply to comment #6)
> Has anyone been able to reproduce this on older versions, or is this specific
> to the version in Fedora 12?

I still hit this issue on Fedora 11 through 13
Comment 9 Keith G. Robertson-Turner 2010-05-22 13:34:05 EDT
Just tested xscreensaver-base-5.11-2.fc12.i686 and can confirm it exhibits similar behaviour, with one important difference.

As with gnome-screensaver, an active file menu will inhibit xscreensaver's animations and locking, and power management will still blank the screen, but (unlike gnome-screensaver) the screensaver animation will not then activate as a delayed response after the system has been reactivated and the file menu has been dismissed.

So xscreensaver's methodology is slightly more logical and less confusing, but an underlying bug in Xorg ensures this remains a security vulnerability.

Reassigning to component xorg-X11, and changing summary as appropriate.

Still need info from upstream.
Comment 10 Keith G. Robertson-Turner 2010-05-22 13:56:17 EDT
Upstream bug located.
Comment 11 Peter Hutterer 2010-06-03 01:31:58 EDT
(In reply to comment #7) 
> Please verify (from Comment 3) that this is in fact an Xorg bug, so it can be
> reassigned. E.g. does this also affect xscreensaver, or is this Gnome-specific?

It is an X11 design issue. only one client at a time can grab the pointer and keyboard and toolkits to exactly that to provide the usual menu behaviour. You'll see the same issues with e.g. the firefox address bar or any popup menu.

The screensaver locking requires a grab on both pointer and keyboard and exactly that cannot succeed while the menu is open. This isn't a new issue in X, this particular protocol restriction has been present since the first versions of the core protocol.

The issue here exists mainly because dpms is handled in the server but the screensaver is a client.
Comment 12 Vincent Danen 2010-06-04 13:12:04 EDT
It looks like there has been no response to this upstream for four months.  If this is something that is a design limitation, is there anything we can reasonably do about it?  Or is this something that would need some fairly invasive changes to the X11 design?

I guess what I'm asking is whether or not we can reasonably fix this without any apparent interest in it from upstream and considering how deeply rooted in the X11 design it is.
Comment 13 Peter Hutterer 2010-06-08 00:52:34 EDT
<putting my upstream hat on>
We're aware of the issue but there is no simple solution. We've had a fairly long IRC discussion about this last week but to fix this properly, we need to add some new new protocol specifications (and of course the matching implementations).
So yes, it's quite invasive and, worse, time-consuming.
Comment 14 Keith G. Robertson-Turner 2010-07-08 14:13:15 EDT
That's good enough for me.

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