Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 401645 (CVE-2012-1620) - <x11-misc/slock-1.0 : shows top window that was created after locking (CVE-2012-1620)
Summary: <x11-misc/slock-1.0 : shows top window that was created after locking (CVE-20...
Status: RESOLVED FIXED
Alias: CVE-2012-1620
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
URL:
Whiteboard: B4 [glsa]
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-31 15:21 UTC by Longpoke
Modified: 2014-12-12 00:43 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Longpoke 2012-01-31 15:21:57 UTC
If any program makes a modal dialog box while the screen is black/controls locked with slock, and then some buttons are pressed on the keyboard, the screen is unblackened, and everything is visible on the desktop you locked on.

Steps to reproduce:
1. sleep 3; pcmanfm
2. slock
3. press some buttons
4. now black screen will go away and you can see the current active desktop

This is a critical vulnerability. I recommend blocking this package.

I'm running xmonad on amd64.
Comment 1 Jeroen Roovers (RETIRED) gentoo-dev 2012-01-31 17:15:15 UTC
I'll check whether I can reproduce that.
Comment 2 Jeroen Roovers (RETIRED) gentoo-dev 2012-01-31 17:23:28 UTC
1)  In a terminal, I run `slock & sleep 5; <some X app>'
2)  After about 10 seconds, I press some keys that slock would interpret as a
    password.
3a) It does not allow me to use <some X app> - all keyboard controls are captured.
3b) Pointer device input is blocked - <some X app> cannot be controlled through
    the mouse.
4)  Entering the correct password unlocks the screen and makes <some X app>
    focused and in the foreground.

The only harm I see here is a possible unwanted disclosure of the information that <some X app> happens to display at the time, but it's a vulnerability sure enough.
Comment 3 Kurt Seifried 2012-02-01 02:36:03 UTC
Does this issue need a CVE?
Comment 4 Longpoke 2012-02-01 03:41:11 UTC
You need to run the other program *concurrently*. I'll try and make the reproduction steps clearer:

1. run sleep <n>; <X-program>
2. lock the screen as fast as you can
3. make sure <n> seconds has passed, so that you know <X-program> has started
4. press some keys (any keys (doesn't have to be your actual password), don't hit enter)

Now the black screen will go away and you can see the current active desktop along with <X-program>.

Where <X-program> is the name of some X program that will create a window and leave it open when executed, i.e: pcmanfm.
Comment 5 Alex Legler (RETIRED) archtester gentoo-dev Security 2012-02-02 10:23:05 UTC
A bit of analysis:
afaics slock uses XMapRaised(3) to bring the black window on top of *all currently* displayed windows. That obviously doesn't include windows that are created after slock started.

I tried reproducing this using kwin as WM, and it did not work, however using evilwm, it did. So it depends on at least one environment factor as well.

The question is, what to expect from a "screen locker" utility that also advertises itself as "simple". I'd rather think it prevents others from using my input devices and hides information as a bonus (look at xtrlock which only does locking by default and also goes by the name "screen locking program").

I'll email upstream for a comment, as I'm not really sure if this should be treated as a security issue and if it can be fixed at all without losing the "simple" approach. If at all, I would rate it as very minor, and certainly not critical (re c#1).
Comment 6 Alex Legler (RETIRED) archtester gentoo-dev Security 2012-02-02 13:48:00 UTC
Got the following information from upstream (Anselm R Garbe <garbeam at gmail dot com>)
"The issue is already known and we are considering a general fix in the
upcoming 1.0 release (during the next weeks)."

and:
"I consider this as an annoyance only."

If anyone wants to still consider this as a security issue and get a CVE, please state your reasons, otherwise I'll likely be reassigning this to the maintainer in a few days.
Comment 7 Longpoke 2012-02-02 14:43:23 UTC
This is a vulnerability because the implicitly advertised security that this program provides isn't there. It's not hard to understand why this is a vulnerability.

Example:
I'm working at a public place (such as a school campus). I enter my credit card details into a submission form on a website, but don't submit it. I leave my computer (which is chained to the desk). Joe requests to send me a file over chat (causing my a modal dialog box to appear). Then someone comes to my computer, thinks it's not being used by anyone else, so he presses a key thinking it will get rid of the screensaver. Instead it shows my credit card info.

If it blacks the screen at all, it should black the screen always. I didn't see any text stating that screen blocking is intended to only partially work. Will the user go in some readme somewhere in small print and see "oh, btw this program doesn't actually block the screen".

This violates a rule of secure interaction design:
"Clarity. The effect of any security-relevant action must be clearly apparent
to the user before the action is taken." [http://people.ischool.berkeley.edu/~ping/sid/uidss.pdf]

I used this program because I don't need flying dragons and rainbows on my screen (which all the other programs seem to provide), I just want my screen locked, with a minimal trusted code base.

Yes it should be a CVE. (Unless the intended behaviour is for screen blocking not to fully work... but how is the user supposed to discover that fact?)
Comment 8 Jeroen Roovers (RETIRED) gentoo-dev 2012-02-02 16:14:49 UTC
Let's fix that Summary:

1) It does NOT unlock the display (I was wrong in changing that).
2) It applies to all windows, not just modal windows.
Comment 9 Jeroen Roovers (RETIRED) gentoo-dev 2012-02-02 16:16:14 UTC
(In reply to comment #7)
> This is a vulnerability

Yes, you established that in comment #0. Fine, now let's find a solution. :)
Comment 10 Jeroen Roovers (RETIRED) gentoo-dev 2012-02-02 16:45:07 UTC
(In reply to comment #6)
> If anyone wants to still consider this as a security issue and get a CVE,
> please state your reasons, otherwise I'll likely be reassigning this to the
> maintainer in a few days.

Oh now I see what comment #7 is all about. Well, if it's not too much hassle, I'd like to have this treated as a security vulnerability.
Comment 11 Samuli Suominen (RETIRED) gentoo-dev 2012-02-11 15:28:25 UTC
How is slock-1.0?  Or perhaps someone else can look at changes:
http://hg.suckless.org/slock/
Comment 12 Jeroen Roovers (RETIRED) gentoo-dev 2012-02-11 16:56:23 UTC
Version 1.0 handles this better. On a slow/burdened machine, I can see that a window created after slock is started will flash up and then disappear again.
Comment 13 Jeroen Roovers (RETIRED) gentoo-dev 2012-02-17 17:07:34 UTC
Let's wrap this up.

Arch teams, please test and mark stable:
=x11-misc/slock-1.0
Target KEYWORDS="amd64 hppa x86"
Comment 14 Paweł Hajdan, Jr. (RETIRED) gentoo-dev 2012-02-18 14:31:41 UTC
x86 stable
Comment 15 Longpoke 2012-02-18 14:36:01 UTC
"Version 1.0 handles this better. On a slow/burdened machine, I can see that a
window created after slock is started will flash up and then disappear again."

Sure, better, but that's still a vulnerability.
Comment 16 Jeroen Roovers (RETIRED) gentoo-dev 2012-02-18 16:09:04 UTC
Stable for HPPA.
Comment 17 Agostino Sarubbo gentoo-dev 2012-02-20 09:13:47 UTC
amd64 stable


@security: please vote
Comment 18 Tim Sammut (RETIRED) gentoo-dev 2012-02-21 05:21:58 UTC
Thanks, folks. GLSA Vote: no.
Comment 19 Stefan Behte (RETIRED) gentoo-dev Security 2012-02-24 18:48:54 UTC
Vote: YES.
Comment 20 Sean Amoss (RETIRED) gentoo-dev Security 2012-03-06 21:28:27 UTC
Vote: yes. 

Created new GLSA request.
Comment 21 Kurt Seifried 2012-04-06 05:11:13 UTC
Please use CVE-2012-1620 for this issue as per http://www.openwall.com/lists/oss-security/2012/04/06/2
Comment 22 Tim Sammut (RETIRED) gentoo-dev 2012-04-06 06:09:34 UTC
(In reply to comment #21)
> Please use CVE-2012-1620 for this issue as per
> http://www.openwall.com/lists/oss-security/2012/04/06/2

Thanks!
Comment 23 GLSAMaker/CVETool Bot gentoo-dev 2012-07-18 23:11:54 UTC
CVE-2012-1620 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-1620):
  slock 0.9 does not properly handle the XRaiseWindow event when the screen is
  locked, which might allow physically proximate attackers to obtain sensitive
  information by pressing a button, which reveals the desktop and active
  windows.
Comment 24 Sean Amoss (RETIRED) gentoo-dev Security 2014-12-12 00:43:01 UTC
This issue was resolved and addressed in
 GLSA 201412-10 at http://security.gentoo.org/glsa/glsa-201412-10.xml
by GLSA coordinator Sean Amoss (ackle).