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.
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.
Would this be the "hobby" OS that took over running the London Stock Exchange trading platform when Windows couldn't cope?
... 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
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.
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
They did go for C++. On Linux. It was more than just issues with .NET.
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.
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.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
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.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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.
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 ...
It must have been something you assimilated. . . .
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.
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.
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 screenlocker too? Or hell, install a custom keyboard app which looks like the normal one but saves all passwords and sends them to the cloud. I might not even need to root it to do that.
SJW n. One who posts facts.
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 casual intruders, but don't think that it's any more than an inconvenience to a serious attack.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
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.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
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
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!
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.
I'd argue that's not really having access to the computer except for re-purposing its hardware. If the boot/data drive is encrypted, you've gained nothing. A lot of smartphones are encrypted by default when a screen locker is enabled. With Windows, CTRL+ALT+DEL plus a secure password is probably enough to keep you out of an encrypted computer in the short term. In Linux, you could probably bypass an X11 lock screen without much trouble without losing access to the decrypted contents.
And if you do it anyway, expect 120 xeyes windows to pop up pretty soon.
xroach FTW!
Have gnu, will travel.
Security standards like PCI DSS assume that, yes, your users are untrustworthy or, at best, naive.
Gamingmuseum.com: Give your 3D accelerator a rest.
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.
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?
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.
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.
It was more than just issues with .NET.
Really? Now I'm interested. What other problems did they have?
"First they came for the slanderers and i said nothing."
Yup.
"First they came for the slanderers and i said nothing."
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.
Good point.
"First they came for the slanderers and i said nothing."
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
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
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.
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.
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
You're not going to get any of my data that way, which is what is actually important.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Perhaps I should have clarified: attempt to get my data out of it. Of course you can use DFU mode.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Your façade rather falls apart when they actually do press "del", I think.
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.
My ism, it's full of beliefs.
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.
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*
You're not going to get any of my data that way, which is what is actually important.
I'm not sure I follow. Surely if I had unlocked access to your phone, I could simply read whatever data was on there? Also, can you install free apps without an additional password? If so what stops me installing a keyboard app trojan?
Honest question: I don't own an iPhone. If it stops those kind of attacks it would be great to know how.
SJW n. One who posts facts.
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.
I can do that too.... Might take awhile, cost a lot and require disassembly of the device to get to the flash, but if the data is there, there is a way to get access to it. There are devices that "self destruct" when disassembled but I know of no commonly used cell phones with that feature.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
You're stuck there anyways because you can never be sure someone didn't reboot the system, run a keylogger designed to act like the lock screen, and then send your password and reboot the machine.
As the guy you're replying to said, "you know that every step from boot to login, is intended to protect your interests." If you're concerned about someone rebooting the system and running some malware, you should make use of the various features designed to mitigate against that. All PCs these days let you password-protect the BIOS settings, so if you've configured it to only boot from the HD, it's not as simple as an attacker putting in a CD or plugging in a USB flash drive with their keylogger. And for even more protection, you can get a computer with more "enterprisey" features, such as a physical case lock and a chassis intrusion detection switch. If the attacker thinks they'll just open the box up and do a quick hard drive swap or something like that, that's not gonna work. And these days, there's also UEFI Secure Boot. Sure, there are ways to attack all of this, but a BIOS password plus case lock is sufficient for the vast majority of people. If you need more than that, you should probably focus on keeping intruders from getting access to your computer in the first place.
Whether it's user mode per se or not, there are tools to change the behavior of ctrl-alt-delete.
As far as I can tell, that's just a utility that changes the options that are already available in Windows--they're normally controlled via Group Policy. It's not actually running any new code, it's just changing behavior in a way that MS has already allowed. It actually is possible to write your own code that runs when the user presses Ctrl+Alt+Del though; it's called a custom GINA DLL. Of course, if an intruder already has Admin access to install their GINA DLL, it's already too late... The point of Ctrl+Alt+Del is to thwart malware running as an unprivileged user.
PS - The other major thing is that Ctrl-Alt-Delete was originally a DOS-ism that had more to do with dealing with misbehaving, yet not malicious, programs and trying to regain some level of control.
That key combo was selected because no application uses it. Other than that, there's no relation to its use in DOS. Bill Gates has said that he (or Microsoft in general) had wanted a dedicated key for it, but IBM (which was a major keyboard manufacturer at the time) didn't want to add a key for MS. I guess MS eventually had enough clout to get everyone to add the Windows and Context Menu keys, but it wasn't worth changing Ctrl+Alt+Del to use the new keys.
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.
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?
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