Bug 1013721

Summary:	GNOME 3.10 lock screen does not require password to unlock
Product:	[Fedora] Fedora	Reporter:	Stephen Gallagher <sgallagh>
Component:	gnome-shell	Assignee:	Owen Taylor <otaylor>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	20	CC:	awilliam, jbastian, marcus.moeller, security-response-team, sgallagh, vdanen
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	accountsservice-0.6.35-1.fc20	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-11-10 07:15:19 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	980657

Description Stephen Gallagher 2013-09-30 16:18:42 UTC

Description of problem:
Locking the screen does not prevent users from unlocking it.

Version-Release number of selected component (if applicable):
gnome-shell-3.10.0.1-1.fc20.x86_64

How reproducible:
Every time


Steps to Reproduce:
1. Lock the screen either by selecting the lock icon in the system menu or with ctrl-alt-l
2. Move the mouse and drag the "window-blind" up. (Or hit escape)

Actual results:
The session is immediately unlocked.


Expected results:
The user must be presented with a password dialog.


Additional info:
This is a clear security issue.

Comment 1 Vincent Danen 2013-09-30 18:54:03 UTC

I'm assuming this is new in 3.10 as part of the "improved login and lock screens" changes?

Comment 2 Stephen Gallagher 2013-09-30 19:02:42 UTC

I presume that to be the case, as it was working fine before I upgraded to F20 Alpha from F19 (running GNOME 3.8.x)

Comment 3 Stephen Gallagher 2013-10-01 11:38:33 UTC

This is likely to be the same issue reported upstream at https://bugzilla.gnome.org/show_bug.cgi?id=708997

Unfortunately, the upstream bug is public so this security issue is therefor already disclosed.

Comment 4 Vincent Danen 2013-10-04 22:12:18 UTC

Given the upstream bug is public, I'm going to open this one up as well.  Can you find out from upstream if they require a CVE to be assigned or if they've gotten in touch with MITRE regarding that already?

Comment 6 Jeff Bastian 2013-10-22 12:09:49 UTC

*** Bug 1012983 has been marked as a duplicate of this bug. ***

Comment 7 Fedora Blocker Bugs Application 2013-10-22 12:20:17 UTC

Proposed as a Freeze Exception for 20-final by Fedora user sgallagh using the blocker tracking app because:

 There is a significant reduction in the physical security of a GNOME desktop environment if the screen-lock does not challenge for credentials before restoring access to the desktop session.

Such an obvious security flaw in the final release would reflect very poorly on the project.

Comment 8 Adam Williamson 2013-10-22 16:31:01 UTC

+1 FE, but it's odd that I haven't seen this myself - I use sssd against FreeIPA on both my systems and screen locking seems to be working fine.

Comment 9 Fedora Update System 2013-10-28 16:23:42 UTC

accountsservice-0.6.35-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/accountsservice-0.6.35-1.fc20

Comment 10 Fedora Update System 2013-10-28 19:18:03 UTC

Package accountsservice-0.6.35-1.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 accountsservice-0.6.35-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-20100/accountsservice-0.6.35-1.fc20
then log in and leave karma (feedback).

Comment 11 Fedora Update System 2013-11-10 07:15:19 UTC

accountsservice-0.6.35-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.