Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.
- Press the 'Menu' key on the keyboard
- Press 'Esc'
- Focus is now beneath the screen locker
- Press Alt+F2
- Start 'gnome-terminal'
This was sent to bugtraq a couple days ago, but it was actually reported two months before the similar GNOME bug that I ridiculed last year.
And here's another variant of it from August, which is possibly even easier: "Holding menu key causes window flood and desktop freeze." This probably means "hold down the Menu or Super key and wait for gnome-screensaver to run out of memory and crash, unlocking the screen."
One can just use slock.
slock had a bug where pressing return would lead to a segfault a while ago. Debian still has that or a similar bug.
In my experience the reliable way to crash the Gnome desktop manager crap follows this recipe:
1. Run it long enough.
I am to the point now where my default assumption about all software (made by linux kids or not) is that the software is a serious fail. I keep hoping to see some new linux program or whatever where the promotional pitch is not "here's our cool features" but rather "it does X well and here are the steps we took to make it reliable."
Oh gods, this, this. It's unlikely to ever happen though - it seems to me that adding Interesting New Features is baked into FOSS.
I run xlockmore. I also have no menu key on my 1986 IBM Model M. Nor do I have gnome-terminal installed, as I use urxvt on e16.
I entered this comment using a paperclip, a nine volt battery and a steady hand.
I found my hands are not steady enough for that. Also why I stopped trying to hand-solder SMD stuff. :(
Wait, I thought that was your window manager.
Using Enlightenment 0.19.4's built-in screen-locker. Doesn't seem to suffer from this sort of bug.
If it is "built in" to an app that has a list of linked libraries longer than your arm -- then I assure you, it does.
It doesn't have this particular bug, but I'm sure it has several others we don't know about.
I run Kali linux on my pentest box. This does NOT work. Maybe on other installs but not Kali. I've attempted this in Ubunto but still no joy...
not working on my gnome shell 3.16 on arch linux.
Not one of those was gnome-screensaver. A little more precision and less FUD would be appreciated.
What point are you trying to make and/or score here? A little more precision would be appreciated.
The lock screen on Xubuntu 14.04 (light-locker/LightDM) has GTK widgets, but does so using an approach not covered in your first link AFAICT -- light-locker blocks the current session with a black window, then LightDM shows a lock screen on a new virtual terminal. In principle, it ought to be as secure as xscreensaver, so long as you can write a program guaranteed to blank the screen. It could even reuse xscreensaver code to do this.
OTOH, light-locker depends on libgtk. I poked at it for a bit tonight and found a way to bypass it. AFAICT, the attack didn't work on xscreensaver.
Using another VT doesn't sound like a terrible idea, on the face of it. It does mean that locking the screen requires firing up a second X server on a second VT, which in my experience is not fast, but maybe that has gotten better and more reliable these days. That lets you have two separate processes with simultaneous server grabs, which does address the race condition I talked about.
So that design could work, assuming that there's no back door built into both the kernel and the X server that lets you bypass anything that has to do with virtual terminals. But I'm sure there isn't, because that would be crazy.
Oh wait. Nevermind.
The manual page of light-locker says it is forked from gnome-screensaver.
While "use xscreensaver instead" is all very well, and I do, surely the right way to deal with this is in the X server itself: some extension that makes the locker special, rather than just a normal window that tries really hard to hide the stuff behind it.
Funny story: there is one, it's called MIT-SCREEN-SAVER and is accessible via "xset s". Funnier story: it doesn't seem to work as advertised in the man pages.
The MIT-SCREEN-SAVER extension tried to make the screen saver window be special. It largely failed at this (other apps could still pop up windows above it, override-redirect still worked, etc.) Also it was buggy as hell and resulted in X server crashes all the time that were highly system-dependent (crashes with this video configuration, not that one). It's so bad that xscreensaver explicitly does not use it any more, even though the code is in there to try.
Basically the only problem MIT-SCREEN-SAVER solves is, "is the user idle or not". And it's not so great at that either.
But all of that's actually beside the point anyway, because MIT-SCREEN-SAVER does not address the class of bugs we're talking about here. It tried to address a completely other class of bugs. Even if CADT-screen-locker was using the MIT-SCREEN-SAVER extension (and for all I know it might be) it's still implementing key presses with a novel-length set of libraries that have not been audited with the understanding that they are in the path of critical security infrastructure.
There is no simple protocol-extension fix to that problem.
What you're saying is, "build locking and authentication into the X server itself."
Yes, that is the right and proper way to fix this problem. Authentication is an operating system problem not an application problem.
(Which really means you should be saying "build screen locking into the kernel" instead of "into the X server", but I do think people are beyond pretending that X11 is "just an application" at this point.)
Anyway, good luck with that.
Even if someone did try to get such a thing universally accepted, who do you think will have written the code? Yup, the same damned people. This just means that they'd find a way to link the entire code stack that underlies GtkTextField or whatever right into the X server, including spell checkers and popup menu navigators and who knows what else, and you're right back where you started. No, scratch that, you're probably not right back where you started at all: instead of a local exploit you probably end up with a root escalation too.
The problem is not that getting locking to work securely is somehow intractable, or even difficult, or even a lot of code. The problem is that the people working on it are not qualified. After a decade and a half of this, it's time to believe that it's cultural and systemic, not coincidence.
If you believe that locking your screen is something that you should be able to do -- that it is a critical piece of security infrastructure -- then the entire code stack from the bubble-switch inside your keyboard on down deserves the same level of scrutiny as SSL.
So, yeah, good luck with that.
Might as well just run After Dark on a Mac emulator in a web browser.
That sounds like a great idea, but they’d reject it because AfterDark isn’t GPLed. Alas.
Also After Dark wasn't a screen locker.
I'd love to have a screen saver that was a Mac emulator running After Dark, though. That would rule.
And to continue beating a dead horse: if that existed, xscreensaver would keep your screen locked even if it crashed, because it's designed to fail safe.
I read this thread this like competing tags on an alley wall: "jwz was right", and below it, "not repro, works for m--," bleeding down into the asphalt.
Debug Investigation Unit reports another pile of engineer corpses near the docks. Evidence points to them being both the perp and the victim. More at 11.
I'd watch that show. And write fanfic for it.
I'm still running xscreensaver.
In GNOME's defense though, its purpose is to look good in screenshots and be a strong brand, not to cater to the negligible fraction of its potential user base that spends its time obsessing about security.
If xscreensaver created a pre-baked bitmap by rendering a native-styled unlock dialog into an off-screen context, that could approximate a solution to the "we think xscreensaver widgets are ugly because they don't resemble the GTK theme" problem, right? It would be assembled "off line" by an xscreensaver helper util that listens for theme changes, and xscreensaver would just blit that to the screen when it's time to unlock, instead of drawing the current unlock dialog.
Something like that might work (it gets more complicated when you need to display error messages and whatnot, but not impossible), but given that nobody ever even sends me updates to the colors and border widths, I'm not sure that that's what they actually care about.
I strongly suspect that they just care about rewriting things from scratch, because that's fun.
What does that mean?
In the app-defaults file, you can change the look of the unlock dialog to some extent with X resources. Fonts, colors, borders, shadows. Very likely not enough to make it look exactly like whatever-your-desktop-dialogs-look-like today, but surely closer than the default.
But, but... The world is so full of new things, like DBus and logind and people want information on their lock screens - so everything must be reinvented...
http://blog.martin-graesslin.com/blog/2014/05/screenlocker-architecture-in-plasma-next/
Yeah, well, good luck with that.
Like I keep saying, the awful thing about getting it right the first time is that nobody realizes how hard it was.
I love the part where he claims that one of the reasons you shouldn't use xscreensaver is because, when it is explicitly configured to display images of your desktop, it does exactly that.
He can believe, wish and dream what he likes. I think more sensible people give weight to history and precedent.
Windows uses a Secure Attention Sequence right down in the kernel to ensure that only the actual genuine GINA gets summoned when you press C-A-D. And it has the concept of separated desktops so that UI interactions on a lock screen shouldn't impact what's happening in the user's actual desktop that they locked. Seems bullet proof, especially compared to the situation in X.
And I actually believed all this, because it seems central to Microsoft's security design and it's simple enough that you can believe they got it right.
And then last week I tried to unlock the laptop work insists I must use that runs Windows. All I do with that is run a VM, in which I run an OS I can get along with. But Windows obeys the company's policies, such as mandatory screen lock after 5 minutes even in my office. So I came back to find the corporate logo screensaver running. I pressed C-A-D and nothing seemed to happen. I futzed around for a while, and eventually I got the unlock screen, entered my password, and ...
Inside the VM the C-A-D I'd pressed and which Windows had ignored had been acted on, and the VM was in the process of shutting down in response. So between them the VM vendor and Microsoft had managed to screw up so badly that instead of C-A-D only ever summons the GINA the rule is now C-A-D gets passed through to your VM even when at the lock screen where nothing should pass through to the VM.
Truly, you told us so.
Isn't that actually a feature of the VM software? I'm pretty sure at least some of them--I don't remember which--allow you to control whether C-A-D gets passed through to the VM OS or not. GINA is actually designed to be replaceable.
Physical access = game over.. grow up :)
It's the smiley that really sells your well reasoned essay.
I'm just being realistic. You have several attack surfaces of chance: USB, Firewire/other DMA attacks, Ethernet drivers (MITM on the cord to send packets), etc. It is something to stop your child, or co-worker from leaving a surprise letter. I wouldn't ever trust a machine being 'locked down' with the possibility of anyone having physical access. I figured this would be self explanatory.
"Security is impossible so don't try." Got it.
I guess the GNOME kids agree with you.
I actually develop exploit mitigation software...
How nice for you.
Look, here's a tip, free of charge.
If you are making a comment, and your comment could be characterized as any of:
"I knew that", or
"That's obvious", or
"Meh"
then -- stop. You don't actually have anything to contribute. You are just sucking your own dick in someone else's thread, and nobody's impressed.
Just so you know. Hope that helps.
I am actually sorry for the 'grow up' comment. Although, I must stick with the rest....
Did you put in a bug request to GNOME? If so, please drop the URL...if not I'll check around tomorrow..
I'll just leave this here: http://www.jwz.org/doc/cadt.html
CADT linux brokenness with screensavers extends to more than just locking:
Q-110: Help! x11vnc and my KDE screensaver keep switching each other on and off every few seconds.
This stupid, avoidable bug from 2006 still exists in KDE today, under "Scientific Linux".
Another feather in the cap of xscreensaver: if it is configured to turn the display power off it actually does that. The others keep waking up the display and turning on power for various inscrutable system events and then leave the power on. That is not what I want for a laptop-as-server which spends its days with the lid closed.