Why Screen Lockers On X11 Cannot Be Secure 375
jones_supa writes: One thing we all remember from Windows NT is the security feature requiring the user to press CTRL-ALT-DEL to unlock the workstation (this can still be enabled with a policy setting). The motivation was to make it impossible for other programs to mimic a lock screen, as they couldn't react to the special key combination. Martin Gräßlin from the KDE team takes a look at the lock screen security on X11. On a protocol level, X11 doesn't know anything of screen lockers. Also the X server doesn't know that the screen is locked as it doesn't understand the concept. This means the screen locker can only use the core functionality available to emulate screen locking. That in turn also means that any other client can do the same and prevent the screen locker from working (for example opening a context menu on any window prevents the screen locker from activating). That's quite a bummer: any process connected to the X server can block the screen locker, and even more it could fake your screen locker.
Umm..and telnet is insecure. (Score:5, Insightful)
Re: (Score:2)
Qubes graphics virtualization appears to prevent this attack, since there is no way a VM client can use specific X features (it can only report bitmap deltas to dom0) and it can't force a full-screen window (the user even has to jump through hoops to make that possible).
Re:Umm..and telnet is insecure. (Score:5, Informative)
Wow. Way to totally misunderstand everything.
X11(R6) is a protocol.
XFree86 and XOrg are implementations.
Re: (Score:3)
XFree86 is a port of X(11). The protocol it uses has also taken the same name.
So to cicumvent the screen locker... (Score:5, Insightful)
... there has to be a trojan on the system or at least something connected to the X server over the network.
Hmm. I think by this time your security is already out the window and a borked lock program is the least of your worries.
Re: (Score:2)
I see how this could be a problem, but given that desktop Linux isn't all that widespread I see bigger problems in arenas that are much more pressing.
Re:So to cicumvent the screen locker... (Score:4, Insightful)
This has been solved by everyone not following tutorials from the 80s asking them to use xhost + to allow everyone everywhere to connect to your display.
Re: (Score:2)
Sometimes xhost is still necessary when dealing with old hardware. I have a logic analyzer that remote displays using X11R5. It doesn't play nice unless the server has been opened up with xhost.
Re:So to cicumvent the screen locker... (Score:5, Funny)
Reminds me of my university days...
When someone walked away for an extended period without locking their terminal, one of us would sneak over and do a quick 'xhost +' and then wait for them to come back.
Once they sit down and start working again, we would run 2 dozen copies of neko on their terminal, resulting in a mass of little animated kittens chasing their mouse cursor.
Ah, the lost days of innocent fun.
Re:So to cicumvent the screen locker... (Score:4, Funny)
We always just added
echo "sleep 1" >>$HOME/.bash_profile
to their .bash_profile (or the equivalent if they were using something other than bash).
And might have sometimes done:
cp /bin/sh /somewhere/world/write/readable/sh-[username] /somewhere/world/write/readable/sh-[username]
chmod 4755
Re:So to cicumvent the screen locker... (Score:4, Informative)
Re:So to cicumvent the screen locker... (Score:5, Informative)
This was fixed decades ago. Don't issue xhost + and you should be fine. X uses auth tokens that are files in /tmp with mode 600.
FUD (Score:2, Troll)
... there has to be a trojan on the system or at least something connected to the X server over the network.
Hmm. I think by this time your security is already out the window and a borked lock program is the least of your worries.
Thank you! Now I can be sure that these "news" are just FUD.
Re: (Score:2)
Its not FUD when a malware (or bug) with normal privs can open an avenue for physical attack.
If a website/MITM tricks your browser into putting up a tiny context menu, it can allow someone to walk up to your computer later and start messing with it.
Re: (Score:3)
Hmm. I think by this time your security is already out the window and a borked lock program is the least of your worries.
Just because an application is running on your system doesn't mean it has elevation. But if it pretends to be your lock screen and convinces you to put your password into it, it may be able to gain that elevation.
If it's accessing your X server, it's elevated ple (Score:3)
If it has access to draw windows in your X session, it's elevated plenty - it can also log keystrokes at that point.
Re: (Score:3)
I'm not familiar with writing apps for X, but are you saying that every program that displays a window in X can log all keystrokes including in windows that are not associated with that program?
If so, I'm staying away from X for now on.
If not, I'm not sure what your point is. The malicious application would need to display a fake lock screen, convincing enough to fool the user, before the user would type in their credentials. Only then would that app be able to elevate.
Re: (Score:2)
Well try this:
... Ctrl-Alt-Backspace zaps X.
- Find the id of your window of interest (xwininfo).
- Attach to it with xev -id $id
Now that you know
Re:If it's accessing your X server, it's elevated (Score:5, Informative)
I'm not familiar with writing apps for X, but are you saying that every program that displays a window in X can log all keystrokes including in windows that are not associated with that program?
Yes. This isn't just X, by the way; it's a common design across most operating systems. Any client can register to receive keyboard and mouse input regardless of the current focus, unless another client has already "grabbed" the input device. This is how things like global keybindings are typically implemented. Windows used for password entry (including lock screens) can grab the keyboard to prevent other programs from listening in. The problem is that this only works if no other program has already grabbed the keyboard.
Secure input handling is one of the many reasons why everyone is eventually planning to switch to Wayland. Under Wayland, only the compositor has access to the raw input or the ability to inject simulated input events. The compositor manages any global keybindings and forwards the remaining events exclusively to the active window.
Re:If it's accessing your X server, it's elevated (Score:4, Informative)
I'm not familiar with writing apps for X, but are you saying that every program that displays a window in X can log all keystrokes including in windows that are not associated with that program?
Yes. This isn't just X, by the way; it's a common design across most operating systems. Any client can register to receive keyboard and mouse input regardless of the current focus, unless another client has already "grabbed" the input device.
Except in Windows. Since Vista user interface privilege isolation [wikipedia.org] prevents unauthorized processes from grabbing keyboard/mouse events or sending messages to windows owned by another process, even if that process is running as the same user. To be allowed to grab keyboard/mouse, the process must have declared that intent in the manifest *and* it must have been launched from an installed location (program files or windows system). Furthermore, such hooking/messaging is also masked out at the intrinsic level by UAC - specifically by integrity levels. A lower integrity process is simply not allowed - manifest or not - to send messages or install keyboard/mouse hooks at a higher integrity level process.
X is especially bad in this regard, as it does not even protect against shatter attacks and eavesdropping on windows from *another users* processes. If you elevate to root - e.g. sudo from a terminal window - any other process can *still* eavesdrop on keyboard events.
Re: (Score:3)
Some other window most likely does have the keyboard focus, but that's not the same as grabbing the keyboard. Having the focus doesn't prevent input events from also being delivered to other windows, it just tells the non-focused windows to ignore the events. Integrity and privacy for both input and output is a hard problem and something very few windowing systems manage to get right. The solutions tend to involve some degree of inconvenience for the user.
Re:If it's accessing your X server, it's elevated (Score:4, Insightful)
The basic misunderstanding here is the idea that the screen lock in old X was designed for security, and usable as such; it was just a screensaver with a password
What use is a screensaver with a password that isn't designed for security? Why is the password even there? So it looks secure? Lets just admit it was poorly designed from a security standpoint. That's fine, most stuff designed at that time was not secure. MS-DOS had no security at all. Pointing out that NT occasionally has some good ideas is not an indictment against Unix.
Re: (Score:3)
Are you familiar with the traditional attack
Computer somewhere running some OS.
Regular authorized but non-priviledged user logs in and runs regular non-priviledged user-space application "program that looks like lock screen" and then leaves computer.
Another coworker, or perhaps an administrator walks up to use the computer; types in his credentials... and the app saves them...
Windows solution to the attack implemented decade(s) ago:
real windows desktop lock screen can only be unlocked with ctrl-alt-delete w
Re: (Score:2)
Re: (Score:3)
You're tricking yourself into security theater. You can't intercept an actual ctrl-alt-del, but you can read the ctrl and alt keys, and just unlock your fake lock a couple seconds later. For bonus points, as soon as they press ctrl-alt you change the pointer to an hourglass, and wait an extra second, that way even if they're slow they have time to press del. No windows user is going to be surprised or alarmed by 2 seconds of lag. Their brain will probably hold them in a sort of pause mode anyways, because t
Re: (Score:3, Informative)
Uh, okay? (Score:2, Insightful)
If someone wants to fix it, cool, but it's not really going to bother me very much if this behavior continues.
Re:Uh, okay? (Score:5, Funny)
What? I was assured that THIS was the year of the Linux Desktop!
Re: (Score:2)
Re: (Score:3)
Re: (Score:3)
It doesn't bode well for Linux that it is also not the year of the Windows Desktop or Apple Desktop. It is the year of the smart phone. The year of the desktop may never return. Desktops are better suited for developers and smart phones are better suited to consumers.
Developers and a ton of other professionals. If Linux/FLOSS could replace Windows, Office, Outlook/Exchange, Sharepoint and SQL Server that's probably 15 of Microsoft's $26 billion dollar revenue. Open source has not managed to commodify basic business and collaboration tasks, despite so many years of trying. It's not all about smartphones and tablets.
Re: (Score:2)
No no, that is a misunderstanding. This year is the year of a linux desktop. Not The linux desktop.
Re: (Score:3)
It is. They just failed to mention that it was is a year on Pluto.
Re: (Score:2)
It is the year of the Linux desktop! It's just that the Linux in question uses Chrome instead of X11 as its GUI.
Re: (Score:2)
They had to push that back. This is the year of Linux on the Flying Car. We'll get to Linux on the Desktop right after that.
Re: (Score:2)
It is! Unfortunately the Desktop is itself rapidly fading in favor of the laptop, and desktop Linux has power management issues that make it substantially less suitable for mobile applications..
Linux rules the desktop, which is in your pocket (Score:4, Insightful)
The year of the Linux desktop was several years ago. Most new computing devices run Linux, and fit in your pocket.
Re: (Score:2)
What about Steam on Linux, Microsoft charging a yearly subscription for Windows 10*, and nobody wanting to pay to continue using the computer they already bought?
*Windows 10 upgrades within the first year of release come with a free lifelong subscription until Windows 10 is discontinued. Corporate subscription is per-user on unlimited devices, rather than per-device.
Re: (Score:2)
False.
http://www.pcgamer.com/microsoft-windows-10-will-not-be-sold-as-a-subscription/ [pcgamer.com]
Re: (Score:3)
Article is WRONG WRONG WRONG. Screen locker: issue chvt onto another X instance, and spawn a thread that goes into a loop reissuing chvt to hold it there until the unlock password is given.
vlock -asn
This has been solved for a long time. Not sure why this is really an issue.
Re: (Score:2)
This has been solved for a long time. Not sure why this is really an issue.
Because the poster stepped out of a way-back machine and didn't notice ...
Re: (Score:2)
This has been solved for a long time. Not sure why this is really an issue.
Because the poster stepped out of a way-back machine and didn't notice ...
That's one hell of a way-back machine! vlock 1.2 came out in 1998!
not the point (Score:4, Insightful)
Isn't the point of a screen locker to keep a person from accessing my computer while I step away for a moment (to go to the bathroom or refill my coffee mug.) not to prevent programs from accessing things?
Re: (Score:3)
Re:not the point (Score:4, Informative)
What do you mean "think it will kick in"? Activate it when you get up from your desk, period. For Windows it's an easy "winkey+L" combo as you get up from your desk. Done, workstation is secured and locked. That's our company policy anyway, you're supposed to lock your workstation when you step away. A timed lock screen is pointless, stupid and just gets in the way. If your mouse just happens to bounce a little, it'll reset the "inactive screen timeout".
Re: (Score:2)
If you have a laptop it will usually lock when you close the lid, but as the summary said, if a context menu is open it might be prevented. The same when you click the lock key, if you don't check and see that it really launches and locks the screen, it might be that it is not locked.
Re:not the point (Score:4, Insightful)
Shocker.
Re: (Score:2)
I don't have a Windows key, you insensitive clod.
(IBM Model M keyboard from 1996)
Re: not the point (Score:3, Informative)
Re: (Score:3)
Not mine, when I get up the prox card reader sees that I am not near the workstation and instantly locks, it will not even offer an unlock until I am within proximity again.
Really cheap to put in place less than $10K for the whole company. and increases security 80 fold. Problem is most IT departments are not savvy enough to do it nor convince management that it's more important than a new Jaguar for the Director of marketing. Heck my old Dell laptop supported it.
Re: (Score:3)
but in reality will actually just be recording your user name as password so the intruder can use this. They'll get the password, and come back at a time when they have more time to do their dirty work.
That's why I always first try to unlock with "password123" when I get back from the bathroom break I could no longer postpone.
Re:not the point (Score:4, Interesting)
If someone gets physical access to my machine while I'm away and the screen locker has not activated, regardless of OS I am on, I am screwed. Be it Windows where a utility can be run to hook into the keyboard, OS X and a .kext that flashes a custom ROM to the keyboard so it doubles as a keystroke logger, AIX could have the bootlist modifed to boot from an unauthorized rootvg, Solaris could have the root role moved to all users, and so on.
Realistically, X-Windows authentication and running rogue clients has been a non-issue since the late 1990s. By default, X is locked down quite tightly, taking an explicit "xhost +" to undo those measures. Even when SSH-ing into a remote machine, by default, the X-windows port is not authorized or forwarded unless both the client and server are explicitly changed to permit this. These days, relatively few applications are X-windows clients, other than legacy stuff. Most enterprise level items (be it an Isilon, VNX, VMWare vSphere, tape silo, and so on) either have a dedicated client, allow SSH in, or have a web page for their configuration. The last time I've used a X-Windows client from a remote machine was running the NetBackup administrative client application from a master server, because it was the most reliable way I could watch what was going on.
One cannot make light of security holes, but there are things to work on and ones that are too difficult for an attacker to ignore. It takes some explicit commands to force X-windows to allow clients other than from the local machine to connect (including disabling the kernel packet filter or actively allowing connections through it.) So, someone connecting remotely to an X server before xlock activates can be a hole... but it is something extremely hard to take advantage of.
Re: (Score:2)
Those bluetooth locker programs are handy for this, once your phone / headset / whatever is out of range of your computer the lock screen automatically comes on. Some can also be configured for unlock (though that seems like it would add another possible attack surface).
I feel like there would be a market for small bt keychain dongles for this exact purpose.
Re: (Score:2)
Windows used to have so many keyloggers (it was really insecure around 1999 and 2000) that they added the ctrl-alt-delete functionality to make sure only the Windows kernel could grab your password when you logged in, not some keylogger. Now these guys are feeling jealous about that.
I've heard of this as a justification for replacing X11 with Mir/Wayland or whatever, but obviously if this is a desired feature, the solution is to merely add an extra function call t
Re: (Score:3)
"merely add a function to the X11 API" is the problem. X11 is ancient, full of bloat that no one uses any more and not designed with core concepts in mind that are desirable in a modern operating system. Really, look up some youtube presentations from the Wayland guys - who actually work on X11 and listen to what they have to say regarding the complexity and brain damage in X11. It works, but sometimes, even the guys who maintain it don't know exactly why.
The X11 display server is a liability and need
Re: (Score:2)
Good luck ever actually getting rid of it, considering it is what every *nix gui app runs on. Even if the switch to Wayland happens, most people will still be stuck with using XWayland constantly for a decade.
Re: (Score:2)
They may be stuck with XWayland for a handful of apps that aren't being updated, but the work to let modern desktop environments run on Wayland instead of X11 is quite far along. Once the basic KDE and GNOME libraries are ported to Wayland, anything that uses those higher level libraries rather than talking directly to X will run under Wayland without needing any intermediary like XWayland. I
Re: (Score:2)
Virtually every *nix app runs over abstraction layers such as QT, GTK, Pango, Cairo etc. Assuming there are wayland backends for these layers then porting isn't as hard as you think. There may be vestigal bits of X to clean up and some edge cases that need more effort (screengrabbers, video players
Re: (Score:2)
All the same, if some guys can't figure out how their code works, I don't really expect them to go out and do something better in another project. I expect them to make the same mistakes again. Joel makes some good points [joelonsoftware.com]. He says,
"when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don't even have the same programming team that worked on version one, so you don't actually have "more experience". You're just going to make most of the old mistakes again, and introduce some new problems that weren't in the original version. "
Maybe Wayland will be better, that would be great. Odds are against it though, because of how rewrites usually go.
Re: (Score:2)
I don't know - every program that I've ever restarted from scratch has turned out far more powerful and flexible with a far smaller codebase than the original. Lessons learned from the first go-round and all that. With a better understanding of the problem space comes a better ability to address it efficiently.
Re: (Score:2)
Re: (Score:3)
Windows has had the ctrl-alt-del to log in/unlock since literally the first version of Windows NT, 3.1, in 1993. That's a long time to have feature envy, though I suppose it's possible. I generally wonder if the average user is clever enough to understand the implication anyway - if you put up a fake login dialog on Windows just past the ctrl-alt-del, I bet most users would just fill it out and go with it rather than think they're under attack.
Re: (Score:3)
Yes, that is exactly my point.
Nice try. But no, you are BSing.
Scoth: "Windows has had the ctrl-alt-del to log in/unlock since literally the first version of Windows NT, 3.1, in 1993. "
You: "In 1993, Windows didn't have an NT kernel."
AC: "In 1993, Windows NT 3.1 was released. Not to say that the non-NT product line ended at the same time."
(AC factually correct here: Windows NT 3.1 was released in July 1993)
operaghost: "Windows NT 3.1 didn't have an NT kernel? Color me confused. No, scratch that-- color you wrong."
You: "Go to a typical co
Re: (Score:2)
X11 is an arcane and largely obsolete framework. The fact it needs so many damned extensions to be any way functional is precisely the reason that developers are keen to get rid of it. It's not secure, it's filled with arcane and obsolete code and it's terribly inefficient both locally and remotely. Fortunately it'll be moved aside and replaced by wayland over the ne
Re: (Score:3)
Example that might make more sense:
You download a program that appears legit (and may be mostly legit, or be a hacked version of a legit program), and are running it.
The program senses inactivity, opens a contextual menu on the screen to prevent the REAL screensaver from kicking in, and opens it's own fake screensaver instead.
When you get back to the computer, it prompts you to input your credentials.
Voila... it now has your credentials, and can wreak utter havoc and destruction (depending on your permissio
Re: (Score:2)
But why would I do that? Almost all the programs I use come from the repository, and to get me to download one they'd have to compromise the repository first (which is possible, but not nearly as easy as just advertising a program for download). The rest are again ones I download from known sources, usually the developers' own official site, and again it's not trivial to comprom
Re: (Score:2)
But why would I do that? Almost all the programs I use come from the repository, and to get me to download one they'd have to compromise the repository first (which is possible, but not nearly as easy as just advertising a program for download). The rest are again ones I download from known sources, usually the developers' own official site, and again it's not trivial to compromise those sites.
The situation you propose only happens in the world of Windows where downloading random software from untrusted/unknown sources is routine. And if you're routinely doing that, you've got more problems than just a way to bypass the screen lock. The best way to avoid shooting yourself in the foot is to not blithely follow instructions but to stop and ask "Wait a minute, why are they asking me to aim a loaded gun at my foot and pull the trigger?". And if after pondering that question you still think following the instructions is a good idea, please report to HR for reassignment as reactor shielding.
Exactly. I just looked at my programs list installed 99% of non game software came from the repository, the games were installed via steam which is in turn in the repository. the remainder (vmware player, and chrome) is delivered via HTTPS from the official site or from the git repository.
Re: (Score:2)
Well, yes.
However, that only works if the attacker already has arbitrary local code execution. If they can do that then they can trojan every single program, by diddling with the PATH environment variable and/or pissing with LD_PRELOAD.
Basically yes, it's a hole but one that only kicks in if you're fucked 6 ways to Sunday already.
Or if you've done xhost+ and disabled your firewall. But that hasn't been the default in years.
Re: (Score:2)
Re: (Score:2)
No, X11 was designed without screen locking in mind.
Re: (Score:2)
Or security at all, really. X11 is vulnerable to packet sniffing as well (which still requires trust on the host). Really, the solution is use X over ssh, which is also how I start all terminal sessions, as well.I personally usually run from a Windows PC using XMing and PuTTY, but I'll occasionally use an actual box (I use a lot of headless boxes and VMs, though).
Already solved! (Score:5, Funny)
systemd-screenlockerd saves the day!
Of course, it requires systemd-moused, systemd-keyboardd, systemd-windowd, systemd-X11d, and finally systemd-logind. Right now there's some compatibility issues that have been in the bug tracker for a year or so, so for best results you should also ditch KDE or gnome and go with systemd-windowd-managerd and systemd-menud. There's a few incompatible apps as well, if you have problems try using systemd-webbrowserd (requires systemd-networkd) and systemd-xtermd (requires systemd-fontd and systemd-shelld). Thunar works fine though for browsing files, as long as they're in the systemd folder.
Re: (Score:3)
From Poettering himself :
http://lists.freedesktop.org/a... [freedesktop.org]
Re: (Score:3)
check the date: Sun Mar 31 17:22:15
yeah, just a few hours shy of April 1.
Re: (Score:2)
physical access (Score:2, Insightful)
Screen lockers protect against physical access; you're welcome to try and get around an X11 lock screen by tapping at the keyboard. Good luck.
Comparing this to Windows is silly, because Windows doesn't have anything like the X11 protocol. On Windows, running code can disable the screen saver in other ways: patching or replacing DLLs, changing system configuration, etc. No difference from a security point of view.
Re:physical access (Score:5, Informative)
Comparing this to Windows is silly, because Windows doesn't have anything like the X11 protocol. On Windows, running code can disable the screen saver in other ways: patching or replacing DLLs, changing system configuration, etc. No difference from a security point of view.
I'm no Windows fanboy, but this is just factually incorrect.
(1) All those operations require elevation, so unless the user has lowered UAC from the default, they will require authentication. I suppose a malicious installer could do that, but it is emphatically incorrect that any running code can effect that change.
(2) Since 7, when Windows elevates it completely suspends the old 'Desktop' and creates a brand new one for the elevation prompt. If you look closely, you'll realize that all the other 'windows' are actually just a static screenshot of what happened on the unprivileged desktop at the point where the elevation prompt was created.
So "from a security point of view", on Windows you have a specific privilege required to change the SS that is mediated through a privileged interface where it cannot be snooped/intercepted by unprivileged processes.
[ Of course, this comparison is also patently unfair -- Windows 7 was written in the 2000s, X11 was written in the 1980s. Expecting them to be comparable in terms of security is pretty ridiculous. ]
Re: (Score:2)
"Of course, this comparison is also patently unfair -- Windows 7 was written in the 2000s, X11 was written in the 1980s. Expecting them to be comparable in terms of security is pretty ridiculous."
Which could be a good argument for replacing X. It is rather old technology, perhaps it is time to update it to something newer, rather than clinging to it and claiming it is all one needs.
Re: (Score:2)
Which could be a good argument for replacing X. It is rather old technology, perhaps it is time to update it to something newer, rather than clinging to it and claiming it is all one needs.
Or how about adding a protocol extension to deal with this security problem as has been done a number of times in the past for authentication. I don't understand why X11 seems to get special treatment here.
Program has security flaw. Response "has it been patched yet"
X11 has security flaw: we can't possibly patch it we mus
Re: (Score:2)
X11 was written in the 1980s
Written? More like scratched in crayon in the walls of a padded cell.
The architecture of X has always been a mess going back to the very beginning. Need proof? the client is on the server and the server is on the client. 'nuf said!
p.s. notice that you need no elevation for this. This was a common joke back in the pre-security days. You wrote a cool user space application that after a few minutes of inactivity would pop up an xlock clone. The user would then type his/her password and "unlock the screen".
The
Re: (Score:2)
Screen lockers protect against physical access; you're welcome to try and get around an X11 lock screen by tapping at the keyboard. Good luck.
1. CTRL+ALT+Backspace ...
2. CTRL+ALT+F1, CTRL+ALT+F2,
3. ALT+SYSREQ+F
4. CTRL+ALT+KP_MULTIPLY
Maybe you're safe from all those because you disabled all the features that make those work. Are you sure you're safe? Now try "vlock -nas" and see if any of those work.
Re: (Score:2)
The idea of "CTRL+ALT+F1, CTRL+ALT+F2, ..." is that you may get a local vt that DOES have a logged in session. That's less likely these days, but it used to be very common to login to one of those, then run "startx". If you got back to that, you'd just CTRL+Z then "bg" then start running whatever you want as the user.
Less shocking, it also means that, if you have a login, you can login, and thus can start doing more stuff. If the machine is hooked up to networked logins (AD, LDAP, etc) such as is common at
Uses QT for screensaver, complains about security (Score:5, Informative)
KDE uses QT, a gigantic toolkit, to implement the screen saver. In this case the UI relies on QT Quick.
Gnome's screensaver has the same problems with GTK.
Jamie Zawinski, who wrote the standard xscreensaver, has a FAQ page detailing how these are a fundamentally bad idea from a security perspective:
http://www.jwz.org/xscreensaver/toolkits.html
Re:Uses QT for screensaver, complains about securi (Score:4, Informative)
Jamie Zawinski has been wrong before, too, but in this case it's not even wrong. What we're talking about is the X protocol being fundamentally flawed; it's really pretty irrelevant what screen locker is being used.
And yet Jamie's xscreensaver hasn't been shown to be insecure by this guy. He's only proven what jwz said which is that a lockscreen using a toolkit on top of X11 is insecure.
Comment removed (Score:5, Interesting)
Re: (Score:2)
The 90s called... (Score:2)
They want their lockscreen back.
Come on, this is 2015!
People nowadays think that typing into a CLI is low level hacking!
Real men don't lock the screen anymore, they CTRL-ALT-Fn to the first available login prompt, go away, and CTRL ALT F7 back to their session when they return.
Pussies!
Related: jzw (Score:3)
Let this be a lesson... (Score:2)
Let this be a lesson to all of the architects out there who have a tendency to over-generalize, even to the point of abstracting away useful features.
Uh. (Score:2)
Uh.
Why can't I have my screen locker have a passive grab on Ctrl+Alt+Delete or shift+altgr+control+` or whatever, using XGrabKey. That way if someone else installs a screenlock faker then I'll know because it won't respond to the magic key presses.
The thing is on Windows it never worked as well as it ought to. The reason is that if the screen said something like:
"pls entar u r passwordz to login"
[ password box ]
[OK]
"pls wate wile redirecting to http://scamsite.ru/yourbank [scamsite.ru]"
"Pls entar u r bank passwrd thx"
an
Xscreensaver (Score:5, Interesting)
Jamie Zawinski has another explanation why screensavers on KDE [jwz.org] can't be secure:
Like GNOME, KDE also decided to invent their own screen saver framework from scratch instead of simply using xscreensaver.
And Unity:
Guess what, they did it again! Ubuntu Unity's screen-locking framework is yet another rewrite, and it is completely broken, bug-ridden and insecure. At this time I don't have any information on how to turn it off and use xscreensaver instead. If you do, let me know.
He also has a writeup on toolkits [jwz.org], discussing why locking and unlocking is a hard problem, especially when accessibility features are required.
Let me get this straight... (Score:4, Interesting)
Let me get this straight. In order to exploit this vulnerability, an attacker must:
* gain login access to your system via SSH
* hope you turned on X11 forwarding
* be root or your user
* hope you've disabled access control with `xhost +`
* be able to run a fake screen locker program to get your password to the system he's already completely compromised
Yes, someone could still stop by your desk and put in the fake screen locker while you were getting coffee, but if you got up and didn't lock your machine, that's on you, not X11.
I'll file this one under "good enough" security.
Re:Windows reigns supreme (Score:4, Informative)
Would this be the "hobby" OS that took over running the London Stock Exchange trading platform when Windows couldn't cope?
Re: (Score:2)
In terms of a server OS, Linux has good security. The lock screen on X11 in order to keep other out of your logged in session, workstation/desktop usage. It isn't ideal.
the NT Alt-Ctrl-Del is a Workstation thing. Its security is low level to prevent applications from accessing it.
Re:Windows reigns supreme (Score:5, Informative)
They did go for C++. On Linux. It was more than just issues with .NET.
Re:Windows reigns supreme (Score:4, Interesting)
It was more than just issues with .NET.
Really? Now I'm interested. What other problems did they have?
Messaging systems performance. The closed nature of the windows kernel means it cannot be tuned to the granularity required for performance objectives to be met for the messaging systems. Windows may reign supreme on the desktop, however when it comes to serious computing objectives, it's always the year of the *ix server.
As for this issue affecting any enterprise systems, many don't have a GUI on their console, so there is no opportunity to troll there either.
Incidentally, if you want to see a manifestation of this issue on a X11 desktop, pick a program with menus - lets say firefox, position the mouse on the menu so it opens, then leave the cursor on the menu until the screensaver kicks in. After the lock screen kicks in you will be able to interact with the GUI until the task loses focus, then the screen save will lock. It's been around for a while.
Yep, it's a risk for a desktop, if _insert_convoluted_scenario_here_, however it should still be fixed.
Re: (Score:2)
Why is this considered acceptable? Get physical access to my iPhone (for example - Android is probably the same?), good luck getting in.
Sure, with a PC there's a few things that are a lot more difficult to secure (e.g., the boot process) but throwing hands up in the air and giving up because of physical access is a cop out.
Re: (Score:2)
Why is this considered acceptable? Get physical access to my iPhone (for example - Android is probably the same?), good luck getting in.
Huh? This exploit only works if someone has already had access to your unlocked computer long enough to load and run malicious code. It's not like oyu can plonk down someone at a computer wit ha locked screen and have them hack in by being clever.
And if I had access to your unlocked iPhone, could I not root it or whatever the iPhone cracking is called and install a fake scr
Re: (Score:2)
Only because your phone doesn't have the ability to boot from external media by default. Change that and you grant anyone with a bootable flash card/USB drive total access to your phone. In fact with physical access and a screwdriver they could get around that boot restriction as well - worst case scenario they just have to replace the soldered-on flash drive. The extreme hardware integration that makes a phone such a disposable, non-upgradable consumer item does grant you a measure of security against c
Re: (Score:2)
Why is this considered acceptable? Get physical access to my iPhone (for example - Android is probably the same?), good luck getting in.
Sure, with a PC there's a few things that are a lot more difficult to secure (e.g., the boot process) but throwing hands up in the air and giving up because of physical access is a cop out.
Hand me your Iphone, I'll get in... There ARE ways.