Slashdot Mirror
Why Screen Lockers On X11 Cannot Be Secure
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.
Flashback from the 90's: Telnet and X11 are inherently insecure - where's the news in that?
... 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.
I certainly get the technical explanation. Given that I don't think Deskop Linux will EVER be mainstream, this seems like something we've lived with for an incredibly long time, and doesn't affect very many people or systems.
If someone wants to fix it, cool, but it's not really going to bother me very much if this behavior continues.
Do not look into laser with remaining eye.
No surprise here. Enjoy your hobby OS.
linux is mroe secure than anything!!
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?
---Saying gnome 3 is better than windows 8 not so much a compliment as it is damning with light praise.
Yes. But this raises the age old problem which seem to afflict every operating system: protected mode software seems incapable of utilizing protected mode hardware protections. The promise of protected mode (and yes, I date back that far) was that one users processes would be protected from another's. This supposed security issue with X is actually a problem of the OS or kernel: how the hell is a rogue process going to be running on your X server in the first place? Doesn't mean X servers shouldn't also be secure, but that's defense in depth.
It's like my living room: I can walk around naked because I know nobody else is in there, and I can lock the door. Can we please stop chasing every gee whiz new feature and get operating systems back to being secure.
If you have physical access to the machine, all things are possible -- some little screen locker isn't going to keep you out.
Too lazy to log in ..
... 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.
Linux is for people who don't mind RTFM.
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.
If I have been able to see further than others, it is because I bought a pair of binoculars.
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.
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
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.
Whats being attacked is the unix ethos: do one thing and do it well. Capturing the key sequence to lock and faking the screen, while it may be easier in KDE alongside Systemd, is not easy in fluxbox or awesome. Its the explicit lack of widgets or sprockets or mindless dreck like this, and predefined key sequences that are captured by the window manager first. I use i3lock, which would mean attackers would have to find a way to get into /usr/bin to usurp my locker and at that point i have a far greater degree of concern than just the locker. X Forwarding and shared X in general has always been a security concern. ssh-agent should be avoided and if you have work to do on the server, do it in a tty over ssh. And this is the schism: newschool linux wants a sexy user experience that pops out of the box and is unified. They want the user to obey the vision of their design and use user switching, connection sharing, and fancy clock widgets and X just cant be (nor should it) Microsoft Windows. Old fogeys like myself will deck the halls of localhost when and if we want to. And it will always be on our terms, right down to color, shape, and font. Security will be our concern.
Good people go to bed earlier.
I'm glad this post came about. It's a good exercise two very important things: 1) disable remote X sessions and 2) install packages from trusted sources. There, not a problem but I do agree that the X-server code could use some security auditing and revitalize good, secure coding principles.
Fixed that for you.
When you come back from the bathroom, you want to regain access to your own computer. Think about exactly how you do that. Do you press the power button and reboot, and then enter your authentication credentials into a dialog that you know is your login screen, because you know that every step from boot to login, is intended to protect your interests?
Or do you just give your authentication credentials to whatever program happens to be running and is asking for them, and is thereby assumed to probably be your screen locker?
Windows users are all computer experts; you pretty much have to be, to get by. One of the first things they learn is that ctrl-alt-delete isn't maskable in user mode, so they are able to use those keys to authenticate the kernel and be sure they aren't being MitMed when they enter their password. X users, on the other hand, don't generally know of a way, when sitting at their keyboard/monitor, to authenticate exactly what software they're communicating with. So if they give their password to a screenlocker, they might be giving their password to anyone or anything.
The fact that you don't want adversarial persons accessing your stuff, suggests that X screen lockers aren't the right tool for you.
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!
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
What's a screen locker?
Slashdot has stagnated so badly that we're actually having a discussion on why screensavers aren't good security, even in Linux. Surely you jest! Next you'll tell me that running everything as root is a bad idea.
Can you have such a slow news day that time actually starts flowing in reverse? The "that screenlocker is secure enough" argument was pretty much over any time someone pranked the supposedly locked lab PC of another comp-sci student and I'm guessing that was LOOOONG before my time.
Am I missing something or it is the same for Mac OS X? It also doesn't require an "uninterceptable" key combination to get to enter the password when the computer is locked.
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). ...yeah, that is certain something that is no longer used.
pay for my M$ (try our new windows only $100 per year per system) If you don't pay your system will go into limited mode also secure boot is now windows locked any other way can't be done due to the DMCA.
http://www.jwz.org/blog/2014/0...
Perl Programmer for hire
If it has access to draw windows in your X session, it's elevated plenty - it can also log keystrokes at that point.
wake up, people!
Why is this even an issue? Lock down your system as hard as you need for the security level the situation requires and close out remote and root sessions/instances before leaving the desk.
You should do this anyway, on any machine, regardless of a stupid screen locker.
Anyone who trusts a screen locker to protect their data and systems should have access to neither.
Linux users don't lock their screen, they simply trust that noone else can figure out how to do anything unwanted with their highly customized desktop environment without a few weeks worth of trial & error (+ research & forensics).
Or they just switch to TTY and improvise a fun one-line to keep visitors entertained for a while. Don't know... maybe:
while true; do DISPLAY=:0 xset dpms force off; done exit
That ought to do it. I FIXED X11!!!!!11111
Here's an idea. When not using your computer, log out. If not using your computer for a long time, log out and shutdown.
The year of the Linux desktop was several years ago. Most new computing devices run Linux, and fit in your pocket.
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.
It can do the gui and port forwarding for you.
Just comes with a shirt startup daemon
http://saveie6.com/
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.
All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
When I saw the headline, I thought "yeah, nothing new there". But then the article goes on to not mention any of the known problems (I don't remember any specific problems, though) and instead invent a whole bunch of non-existing problems.
The first vulnerability is with their own code. Ok, fine, he's probably right on that one.
Then he goes on to post an example program that can prevent your screen saver from kicking in, if you run the example program first. An easier way would be to disable the screen saver, and that doesn't require downloading malicious code.
The next one is allowing other users access to your screen. I.e. the bad old xhost +localhost, which as been recommended against for the last 20 years. And if you do it anyway, expect 120 xeyes windows to pop up pretty soon. As long as you don't open this, there IS the MIT-MAGIC-COOKIE preventing random users from accessing your display. He then goes on to mention SSH, with the comment "If you don’t control the remote side it could mean that the client you start is modified", which is the reason that SSH comes with X11 forwarding turned off by default, and you don't enable it when connecting to servers you don't control.
You don't need to involve screen locking at all, if you random people access to your screen/mouse/keyboard, someone could easily run a key logger.
So yeah, if you override the built in security, it won't be secure.
The rest of the article simply takes it from a misinformed article about locking on X11 to being a Wayland ad. The problem with that is that this Wayland ad is also sending the message that "Wayland is so bad we need to lie about the competition".
Xorg works PERFECTLY FINE, there is NO REASON to use another windowing environment on *NIX machines EVER. FUCK hardware acceleration, FUCK Wayland and FUCK YOU!
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.
Also, this has been known for years and it's been discussed to death already as part of the insanity surrounding Wayland's development.
2001 called, they don't even want YOU back.
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"
"Pls entar u r bank passwrd thx"
an appalingly large number of people would have dilligently followed those steps. the ctrl+alt+delete thing was fine but required more knowledge than 99.9% of users had.
Oh and the active grab thing: if you ever hear a wayland dev tout that as a problem, please kick them in the nuts because it XFree86 USED to have a feature for killing grabs from a keystroke, until the fuckers who went on to develop Wayland decided we didn't really need it because "it would only be needed if a program is buggy". Well, no fucking shit hotshot.
SJW n. One who posts facts.
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 which user-land non-priviledged apps can't intercept.
train users never to login to a computer unless they hit ctrl-alt-delete to unlock it first.
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
Jamie Zawinski has another explanation why screensavers on KDE 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, discussing why locking and unlocking is a hard problem, especially when accessibility features are required.
Ask me about repetitive DNA
Here's the problem: if you care about security to the point where screen locks are serious business, you've gotten yourself into a contradictory set of requirements: both trusted and untrusted users have physical access to and execution priveleges on a terminal. If you really suspect that your users are untrustworthy enough to steal credentials in this way, the answer is to not have a screenlock at all but to push the security barrier further into the system. The terminal is dumb and has no security model, but to access and/or interact with your proprietary information, the user types credentials into your own custom coded application or web form through a browser and it logs him out after N minutes and requires reentry of the credentials. He's not allowed to run any code on your system, and all the directories, executables and shell scripts that are run in the course of interactring with the terminal are marked 755 or 744 as appropriate so that he can't modify them, and the tmp dir resides in a ramdisk that gets wiped between sessions. Then it doesn't matter if everything is permitted over the X11 protocol, because there is no way to spoof anything from that untrusted terminal. Physical security goes a long way in obviating risks from software vulnerabilities, where practical. And if the data being guarded is sufficiently important, it will be made to be perceived as practical.
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.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
If you consider micro-HDMI output and bluetooth keyboard support a "desktop" then I guess nobody will stop you.
Interesting. I never knew real work could be done on a phone. I guess I've been doing my job wrong for years now. Just think of all the time I could have saved by removing 98% of my visual workspace, as well as my full size keyboard and mouse! Maybe I should just move my workflow into the cloud too!
Security standards like PCI DSS assume that, yes, your users are untrustworthy or, at best, naive.
Gamingmuseum.com: Give your 3D accelerator a rest.
So, the success of desktop Linux is in turning an OS into a spying device for an advertising company with a cute name. Come to think of it, all their servers run Linux too. Way to fucking go !
They have prettied it up quite a bit, but the underlying protocol is still there. I can run X applications on my Ubuntu 14.04 box, and they display just like they used to 20 years ago. The colors are a bit different, but the basic protocol is still there.
I may be wrong but this applies to the lock screen/screensaver, not the login screen.
One can use the "switch user" option to leave their X session open and bring them back to the login screen.
Yeah that doesnt work.
If it's sitting there on what looks like a normal login they will not hit CTL-ALT-DEL they will just type away. Hell it's hard to not get users to open up every single attachment no matter where it comes from or to not click on every pop up window they get.
Do not look at laser with remaining good eye.
It's called XGrabKeyboard, and xlock and most (all?) ssh-agent guis already do this. You can detect if the grab failed, and refuse to proceed in such situations. And if the grab is ripped from you, you get an event. which you can at least use to display a big angry error. it almost never happens unless there is a rather poorly behaved app running on your desktop.
Spoofing a lock screen is trivially possible on X11. It's possible on Windows using a driver, but it's not trivial. Supplying a challenge image on the lock screen helps with the security quite a bit, but it is not standard practice for home desktops. And only a few UNIX-savvy businesses bother to establish such a requirement.
X over the network is not secure. so don't even try it if you give a crap about your password. It's not secure even tunneled over SSH, because it's not secure in multiuser environments.
Secure input handling is one of the many reasons why everyone is eventually planning to switch to Wayland.
Right - because inventing a whole new windowing system is easier than creating an X extension to add the necessary functionality.
But my assumption was that some control in the other window already has keyboard focus.
All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
Desktops are better suited for developers and smart phones are better suited to consumers.
Then what's better for people in the middle? They're not "developers" because they are not directly involved in the production of computer programs, but they're not "consumers" because they do not exclusively view works created by others. Besides, schoolchildren are "developers" in training now that "introduction to computer science" has been added to high school curricula.
On this PC (Windows 8.1 with Classic Shell), it's Ctrl+Esc (opens Start), Alt+U (opens Shut Down menu), Down, Down, Enter. It's probably similar for Windows 7. Which operating system is your PC running?
Sure are a lot of rose tinted articles about Windows on /. lately...
The lock screen and the login screen are different things in X. Typically on X ctrl-alt-backspace will kill the X server and give you a fresh login screen. I always thought that the assumption is that propagating this behavior from login to unlock has too many gotchas to be worthwhile. In an environment where security is essential, you should always log out instead of locking and hit ctrl-alt-backspace before you log back in.
"Linux" is already something of a 'cute' name, a man named Linus applied his name to his reimplemented UNIX-type kernel...
Do not look into laser with remaining eye.
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.
Nobody above or TFA by the sounds of it (but I haven't read it) has mentioned the real attack vector - not unlock, but login.
On a shared computer (uni PC room, hot desk, library etc), a valid (but malicious) user logs in, and launches a login look-a-like, then walks away and collects the credentials of unsuspecting users. When a user tries to log it, it could give them an error or log itself out and return them (confused) to the real log in, whatever - you've got their creds.
No comprise or trojan needed (apart from the deliberate one).
So always hit CTRL-ALT-DEL before logging into Windows, even if the login screen is already there. On a Linux box this is most likely to reboot the box - but that's fine too, as it gets you to a known good state (assume again no comprise, and you trust the admins).
But clusters of shared use Linux boxes are unusual outside CS departments - I wonder what they do about this actually? Getting caught is quite likely, so who is stupid enough to try it? Students.
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.
6th Street Radio @ddombrowsky
Naive is a version of untrustworthy. Ask your Nigerian Banker.
I think we've pushed this "anyone can grow up to be president" thing too far.
In Windows 98 you could press ctrl-alt-del and kill the screen saver process, even if IT was password protected.
Talking about screen locking done right.........
Yeah, I wrote a custom lock screen for X in 2000 for an internet kiosk, and I grabbed the pointer and there was no problem. In my case of course it was controlled by a bill acceptor, not a password.
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, it wasn't intended as a security device and people who needed a security device just used one. It is open source, we're not locked out, we're not forced to use the provided default tool.
TFS claims they "can't" be secure because... linux didn't copy windows. Well, geeeeeeeeeeeeeee. If I'd used windows for my kiosk, it would not have increased security. And even here, it would not be easy to integrate a custom setup with the windows feature, so I wouldn't have been able to actually use it; it wouldn't have provided the claimed security.
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 they're so used to waiting to be allowed to continue.
And the more often they have to press a magic key combination, the more robotic it becomes and the less attention they will pay. Also, even if something looks slightly off, they've been taught that this magic key protects them in this situation, so they won't worry much.
The good news is, on X11 platforms, anyone can write their own lock screen program.
The bad news is, on X11 platforms, anyone can write their own lock screen program.
I know you never heard of the OTG standard, but you don't have buy a special cable to try it out. Just cut open the micro USB cable and solder the unused pin to the ground pin, and now you can use that cable to attach standard USB keyboards, etc. to your portable linux device.
See also: http://en.wikipedia.org/wiki/U...
Not sure what your point was about the HDMI, that is what all modern screens expect.
Great idea. Now you can have either a keyboard OR power. I have an OTG cable. It's useless for anything but a quick use.
That's great, but if the terminal you're logging in with is compromised by the old fake login, then all your keystrokes into your super trusted proprietary app or browser session can be logged and then your passwords into THAT system are now compromised, not to mention screen grabbers which might have sucked down whatever secrets you were trying to keep. Your theory about supposedly "pushing security further into the system" is a mere placebo. There is nothing inherently more secure about a browser than about an operating system.
Oh, and if you think a dumb terminal solves it, firstly these days terminals are never dumb. Even dumb terminals (does anybody still actually buy them?) probably run something like Linux underneath.
And if you can find a truly dumb terminal and solve all those problems, then you can stick a little thumb drive sized linux server between the ethernet port of the terminal and the rest of the network. Then it can put up the fake login screen whenever it wants, and at other times just pass through the packets.
This could be solved by requiring the terminal to use encryption with the key securely input into the terminal, but who is actually using such a scheme? I doubt anybody is.
even those that don't display a window but relies on user input has the potential to be a keylogger or have one as part functionality. Word processors, for one. The desktop manager, for an example of the latter.
If you don't want keystrokes to be logged, unplug your keyboard.
Political debates have me rolling my eyes so much I think I got optical whiplash. I should sue. - Foamy The Squirrel
Of course the screen lock in X was a security device; back when X was designed most workstations were shared.
XScreenSaver has some atrocious code to work around the deficiencies in X. Most of the time it succeeds.
Finally! A year of moderation! Ready for 2019?
the stock Nokia Lumia 610 has Mobile Office which is a necessarily stripped but still fully functional port of MS Office for desktop.
Political debates have me rolling my eyes so much I think I got optical whiplash. I should sue. - Foamy The Squirrel
Exactly. You need to control the hardware with physical security, or none of your fancy software solutions are valid. And yeah, then you have to worry about vendors, and where the factories are, and do you pay your security guards enough.
What exactly would you propose to add? This isn't a matter of implementing new functionality, but rather removing fundamental misfeatures. Any change to address this issue is going to end up breaking existing applications which depend on the original input behavior.
In any case this is hardly the only reason to switch to Wayland. It's just one of many areas which highlights the drawbacks of trying to tack modern best practices on top of an aging framework. Better to adopt a clean and modern design as the base and confine the hackish workarounds needed to support older clients to a separate compatibility layer.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
Since X screensaver/locker is just an ordinary full screen window on top of all other windows, there is nothing preventing applications from creating windows that will appear over it, even by accident. I've seen some apps behaving like that. For example kadu, an instant messaging app, has/had this bug where it will show new message balloons/notifications over xscreensaver exposing your private communication.
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.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
Crippleware on Windows always used to amuse me. Oh you've disabled the button because I haven't paid? [poke]...[poke]... There now it's enabled again. Oh, you forgot to check if it should be enabled when processing the click event? Tough.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
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.
This. Or the fact that there are registry entries that allow remapping of any key to any other, including (as far as I remember) the Ctrl, Alt and Del keys. The "security" of Ctrl+Alt+Del has always been over-hyped :-)
Need to type accents and special characters in Windows? Use FrKeys
Out of about 300 computers at work half have Windows 7 (which isn't bad, really) and the other half use linux.
All- repeat ALL of our security issues come from the Windows side.
In the three months I have been there I have had to completely redo 15 or 16 Windows systems due to malware, plus the few dozen that our automated tools were able to clean up.
I have replaced 2 old linux machines (P3 era) and a number of ancient servers have been retired and replaced with VMs.
The linux stuff gets replaced when the HARDWARE quits.
The Windows stuff doesn't last long enough for the hardware to die.
Screenlockers are far from the biggest worry!
It's. You've obviously never seen X.Org's code. Belive me it is.
Reminds me of the good old days of the early 90's, when you could just keep typing in the xdm password field until the buffer overflowed and it would dump you into a root shell.
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.
Except the moment they complete the ctrl-alt-del combination, the system will handle it and do whatever it normally would under such conditions (eg switch focus to regular lock screen, launch task manager, bring up UI with lock/taskmgr/change password options etc). Your custom malicious login screen can't prevent that, which is the whole point of the ctrl-alt-del requirement.
Most new computing devices run Linux, and fit in your pocket.
This is false. Linux is popular, yes, but it's not running on "most new computing devices" by a long shot.
What exactly would you propose to add? This isn't a matter of implementing new functionality, but rather removing fundamental misfeatures. Any change to address this issue is going to end up breaking existing applications which depend on the original input behavior.
Oh how about a new protocol extension that allows one designated program to receive all keyboard inputs regardless of any other grabs. The X11 server can keep on pretending that the other grabbers still have such a grab.
Look: X11 works on Windows even though windows can apparently REALLY gab the keyboard. X11 will we are told work on Wayland too despite the fact that wayland can apparently REALLY grab they keyboard. Do you really think it couldn't be extended to do that itself?
SJW n. One who posts facts.
In 2014, there 1.3 billion mobile devices sold. 82% of those run Android, so just over 1 billion Android devices. Over the same time period, 160 million PCs were sold.
Crippleware on Windows always used to amuse me. Oh you've disabled the button because I haven't paid? [poke]...[poke]... There now it's enabled again. Oh, you forgot to check if it should be enabled when processing the click event? Tough.
If you're going to pirate the software, you might as well go ahead and pirate the full version; then you won't have to poke at it.
OTOH, if you're going to legitimately use the software, you ought to pay for it.
I don't care if it's 90,000 hectares. That lake was not my doing.
For one thing, not having direct remote access, and another, since it's totally independent of X, they could put in either that same key combination of CNTL-ALT-DEL or something similar - CNTL-ALT-ESC to lock the screen.
What part of "X has problems at the protocol level" did you not understand?
Oh how about a new protocol extension that allows one designated program to receive all keyboard inputs regardless of any other grabs. The X11 server can keep on pretending that the other grabbers still have such a grab.
I'm not really sure how creating yet another way for a "designated program" to monitor input events is supposed to address the problem that any X11 client can monitor keyboard events on any window in the absence of a grab, unless you intend to rewrite all existing software to grab the keyboard on receiving input focus, and force all the desktop environments to implement support for the extension and move their global keybindings into a specially designated client. At that point you might was well switch to a system designed for secure I/O from day one—like Wayland.
Look: X11 works on Windows even though windows can apparently REALLY gab the keyboard. X11 will we are told work on Wayland too despite the fact that wayland can apparently REALLY grab they keyboard. Do you really think it couldn't be extended to do that itself?
It's no different with a rootless X server on Windows. Input received by any X window can be observed by any X client, unless one client grabs the input. XWayland will probably work the same way, with native Wayland clients secure from each other and from X11 clients but no isolation between X11 clients and no support for grabbing input directed at non-X11 windows. XWayland is meant as a shim between the Wayland compositor and ordinary X clients; it doesn't support external window managers and isn't expected to host a full X11 desktop environment. You wouldn't run something like a screen locker as an X11 client under XWayland. It wouldn't be secure, for the same reasons that screen lockers aren't secure under X11 now, and similar compatibility problems would occur if you tried to implement the Wayland input model with X11 extensions.
It's easy to implement the insecure X11 model on top of a secure system. The reverse is much more difficult.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
Then show an actual exploit against xscreensaver. Put up or shut up.
Won't they be a bit confused by the task manager window or the fullscreen options screens that inevitably pop up upon issuing such commands on windows?
Your façade rather falls apart when they actually do press "del", I think.
Lockscreens in general only exist to satisfy PHBs and annoy the user. If you really cannot trust the physical security of your office environment for more than 10 minutes, you probably should not be trusting it for even 1 minute and be locking your system through other means.
Someone had to do it.
Supposing there is no way to close it faster than it renders, sure they will be confused, but most will just blow it off as just another windows UI flub, close it, and enter their password.
Someone had to do it.
That's the whole point of the article. You don't need an exploit, X11 is not secure. Anything else can prevent the screensaver from locking the screen (by e.g. opening a menu) and then fake the real unlock screen. Like in the source code given in TFA.
Look, the guy at the top saying "Well duh, telnet isn't secure either," has a valid point. X11 was never designed to be secure, which is one reason why it does the things that it does. This has nothing in particular to do with screensavers, less to do with any specific screensavers, and absolutely nothing to do with Jamie Zawinski's prejudices about large software projects being inherently insecure.
This article is saying that one of the things that we've learned in the 30 years since the X11 protocol was written is that display managers should have the concept of security baked in. Handling input should probably not be a free-for-all, and the mechanism for handling screen locking should probably not be the exact same mechanism used for pop-up messages (i.e. put a window on top and grab all input). It's also not the case that an exploit against xscreensaver would be an argument for or against either the use of widget libraries or any security concerns involved in display manager design.
If it helps you can think that you won the argument by virtue of there being no exploits against xscreensaver. Then you can be happy by winning with non sequiturs arguments that no one else is even having.
Is install Linux on your "Windows NT" workstation and emulate Ctrl-Alt-Del login screen? Or insert a little keylogger between keyboard and computer's USB port? Or hide a little camera in light fixture of the ceiling to snoop on your password? Or just to a little old fashioned shoulder surfing?
Best realize that your password is vulnerable to a determined attacker and practice defense in depth.
...but you _can_ make secure screen lockers on it, you just need to use it raw and not use bloated frameworks. It's been done for years.
There is nothing wrong about considering to replace X11, however the current crowd of desktop developers probably won't make it much better. Instead of learning from modern operating systems like Plan 9 and using language neutral file system based interfaces, systems like Wayland still are stuck in the past requiring dynamically linked libraries as API interfaces.
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 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.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
The same reason I have a locking desk drawer with a wimpy lock that a professional thief could easily defeat: it keeps co-workers from gaining casual access.
The same reason I lock my car doors, and it generally prevents theft. They can still break the window or use other access techniques; my car is not actually secured. I wouldn't leave something important in it though, like a HD full of confidential customer information.
So even a not-fully-secured workstation benefits from casual access control. But thinking it is secure might prevent the creation of more secure systems to store confidential data.
Knowing the real level of security achieved is vital to assessing how your processes meet your security needs.
First bear in mind the attacker has local code execution. If they can put up a fake screengrabber, it's just a logout/reboot away from running a trojaned compositor (if you use Wayland), a trojaned screenlocker (if you use X) and on either system without even a reboot, a trojaned browser, terminal, ssh program and so on and so forth. So to say this is a serious flaw with X is hyperbole.
The next case is that you also claim Wayland is secure. Therefore X11 running on Wayland is secure. Therefore in that case X11 is being run in a secure manner. I claim that if that is the case, then X11 could very easily be secured, because it's eassy to see it in operation nowrunning in a way that the additional insecuritu doesn't break things.
I'm not really sure how creating yet another way for a "designated program" to monitor input events is supposed to address the problem that any X11 client can monitor keyboard events on any window in the absence of a grab, unless you intend to rewrite all existing software to grab the keyboard on receiving input focus, and force all the desktop environments to implement support for the extension and move their global keybindings into a specially designated client. At that point you might was well switch to a system designed for secure I/O from day oneâ"like Wayland.
OK, I'm lightly lost so I'm going to swing back to the original point.
First there's the one about server grabs which prevent other windows from opening. Well, you could easily have a protocol extension that allows only one connected client to bring up windows anyway. The continuation of the grab could either be faked to the grabber, or killed outright (the latter feature---killing grabs---was removed from Xorg by the wayland people because they decided we didn't need it!). Let's say it's first come, first serve, so that the first client to request this feature is the only one to get it. Or the screenlocker could get that command. This requires the WM and screenlocker to be run on boot before a trojan, but as I pointed out, if the system is that deeply trojanned anyway, then this is all pointless.
That requires some rewriting to whichever screenlockers you want to add the feature to, hardly a major undertaking since there's about 3 in common use and a few, more obscure, ones.
The other problem---a designated screen lock key combo. Well, if the screen locker has a passive grab on ctrl-alt-delete, then the fake screenlocker can't grab that, so that already works.
It's easy to implement the insecure X11 model on top of a secure system. The reverse is much more difficult.
Why? Why not have exactly the same security model? You haven't explained, only asserted, that your chosen security feature couldn't be easily available under X.
In fact when it comes to locking things down, there are things like the X security protocol, which blocks untrusted programs from executing various protocol commands. This already exists and could (I haven't checked if it does) easily block things like receiving events from a window on another connection, reparenting or redirecting a window on another connection, diddling with the global keymap and so on.
Anyway if there's unsanboxed local code execution, you're basically screwed on any system.
SJW n. One who posts facts.
Actually, even before Vista, the requirement to press Ctrl-Alt-Del before you entered your password solved the rogue screensaver problem nicely.
No ordinary process can intercept the key combination and when pressed, takes you to a secure desktop that ordinary program cannot draw on so they cannot fake the password screen.
But when you do actually press the Del key, the real password dialog appears, and it is on a secure desktop (the "Winlogon" desktop) that can't be manipulated by your rogue program. Your window would be seen only after the user entered their password once, which would look quite suspicious.
This
Actually. No. Not this.
Or the fact that there are registry entries that allow remapping of any key to any other, including (as far as I remember) the Ctrl, Alt and Del keys. The "security" of Ctrl+Alt+Del has always been over-hyped :-)
Yes, you can install a keyboard driver, usb filter driver, or adjust the keyboard scan code map in the registry to disable the keys. (And that's not in HKEY current user.)
You aren't going to be tampering with or installing of ANY of that from user land. And if you have root... you can just install a keylogger be done with it. Why bother with dorky fake lock screens?
You aren't going to be tampering with or installing of ANY of that from user land.
I think you're confusing the user vs administrator distinction with the userland-vs-kernel-mode distinction... but never mind...
And if you have root... you can just install a keylogger be done with it. Why bother with dorky fake lock screens?
What I'm saying is that the "Ctrl+Alt+Del protects your password" claim is overblown; the suggestions you give only amplify that, as they are even more ways to circumvent it...
Need to type accents and special characters in Windows? Use FrKeys
I think you're confusing the user vs administrator distinction with the userland-vs-kernel-mode distinction... but never mind...
Deliberately conflating, but not confused.
What I'm saying is that the "Ctrl+Alt+Del protects your password" claim is overblown; the suggestions you give only amplify that, as they are even more ways to circumvent it...
But none of them are trivial to do. Especially if I am not already an administrator on the system.
I can trivially run a program to throw up a screen that looks like the login screen on a PC at work. TRIVIALLY.
the "Ctrl+Alt+Del protects your password" claim is overblown
Its like door locks. Nobody anywhere claims they make your house secure, but it does stop people from being able to literally just wander into your house.
In the real world door locks prove to be highly effective at keeping people out of places. From hotel supply closets and building electrical rooms to the bosses office to your bathroom stall while your taking a crap.
Nobody here is arguing ctrl-alt-delete is some magical super thing, its just a door lock. But its enough of a hassle to get around, that its plenty to stop all kinds of casual intrusions and mischief.
Ctl-Alt-Delete is the same way.
Deliberately conflating, but not confused.
It's hard to tell the difference from here ;-)
I can trivially run a program to throw up a screen that looks like the login screen on a PC at work. TRIVIALLY.
Adding a registry entry to remap keys is pretty trivial, too... as, for that matter, is running a different OS which doesn't treat Ctrl+Alt+Del in a special way! Thus any extra security provided is minimal. Which is fine - as you say, security doesn't have to be perfect in order to be useful - but in my view overselling the effectiveness of a measure is counterproductive.
Nobody here is arguing ctrl-alt-delete is some magical super thing,
Alas that is exactly what Microsoft claimed for years (possibly still claim?)...
Need to type accents and special characters in Windows? Use FrKeys
Adding a registry entry to remap keys is pretty trivial, too.
You need to be an administrator to do that. That makes it pretty non-trivial.
is running a different OS which doesn't treat Ctrl+Alt+Del in a special way
Now your suggesting what exactly? That the attacker is going to throw in a linux live CD, boot it, run his 'fake login screen' that looks like the usual windows screen?
Ok... yes I guess that is a theoretically possible attack; although you'd probably get caught as soon as the user isn't actually able to log-in and IT gets called in...
Usually the fake login screen attacks "fail" with a you got your password wrong message, and then quietly disappear and throw the -real- lock screen up so the unwitting user tries again... gets in to what he expects and assumes he must have fat fingered his password.
BTW: I changed my screensaver password to not be my login password. That kind of avoids some implications of this.
Why is it a fake?
Assume i have gnome-screensaver, kscreensaver and xlock installed. now i use one of them to lock the screen. do all the others now cry, because the used one is a fake to them?
I'd hardly call that Linux. And I'd hardly call that a desktop either.
Android / Linux is the most bastardized form of Linux there has ever existed. It is atrocious.
Adding a registry entry to remap keys is pretty trivial, too.
You need to be an administrator to do that. That makes it pretty non-trivial.
It would, except that users having Admin access is much more common on Windows systems. (Being an Administrator on Windows does not (in theory, at least) have the complete "game over" privileges that "root" traditionally does on Unix-based systems, so there are still further privilege levels to be escalated to.)
is running a different OS which doesn't treat Ctrl+Alt+Del in a special way
Now your suggesting what exactly? That the attacker is going to throw in a linux live CD, boot it, run his 'fake login screen' that looks like the usual windows screen?
Ok... yes I guess that is a theoretically possible attack; although you'd probably get caught as soon as the user isn't actually able to log-in and IT gets called in...
Why would IT get called in? After the user's entered their password, you just display a simulated BSOD and then reboot into the genuine OS; no user will be remotely suprised ;-)
Need to type accents and special characters in Windows? Use FrKeys