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.
I'll check whether I can reproduce that.
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.
Does this issue need a CVE?
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.
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).
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.
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?)
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.
(In reply to comment #7) > This is a vulnerability Yes, you established that in comment #0. Fine, now let's find a solution. :)
(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.
How is slock-1.0? Or perhaps someone else can look at changes: http://hg.suckless.org/slock/
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.
Let's wrap this up. Arch teams, please test and mark stable: =x11-misc/slock-1.0 Target KEYWORDS="amd64 hppa x86"
x86 stable
"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.
Stable for HPPA.
amd64 stable @security: please vote
Thanks, folks. GLSA Vote: no.
Vote: YES.
Vote: yes. Created new GLSA request.
Please use CVE-2012-1620 for this issue as per http://www.openwall.com/lists/oss-security/2012/04/06/2
(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!
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.
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).
