| |||||||||||||
DRI3000DRI3000Posted Feb 12, 2013 9:04 UTC (Tue) by alankila (subscriber, #47141)In reply to: DRI3000 by renox Parent article: LCA: The X-men speak
Applications that masquerade as other applications for the sake of fooling user are a fairly well-known security threat ever since someone printed "login: " on their unix terminal with the intent of capturing the next user's credentials.
I can't see a way to usefully constrain random application's behavior such that this couldn't ever be a problem. That's why security-conscious people invented the ctrl-alt-del keystroke combo that can't be caught by applications and which will always present the system log-on prompt. After that people can be instructed to follow a procedure that ensures that login details won't be written to program that merely looks like system's login prompt.
If security relies on user identifying windows and acting based on what they look like, I guess security can't be attained. The pixels are always under attacker's control, one way or other. And I know of no way to sensibly secure, say, policykit's authentication prompt. Anybody can fake that, it's just a window... I have some hope that Weston for instance could make it impossible to make ordinary windows behave quite like security-critical windows. Microsoft chose to train people to look for darkened desktop with a single authorization popup window in middle of it. I've no idea if this is something no other application can fake, or what the point of that is, but it is a tough problem to solve.
(Log in to post comments)
DRI3000 Posted Feb 12, 2013 9:36 UTC (Tue) by renox (subscriber, #23785) [Link]
> I can't see a way to usefully constrain random application's behavior such that this couldn't ever be a problem.
Having the display server setting the tittlebar instead of the application is a start with server side decoration. Provided there is a 'secure' way for the display server to have such information of course..
> That's why security-conscious people invented the ctrl-alt-del keystroke combo that can't be caught by applications and which will always present the system log-on prompt.
A *very incomplete* solution, a trojan game could spawn a window looking like a webpage..
DRI3000 Posted Feb 12, 2013 11:42 UTC (Tue) by NAR (subscriber, #1313) [Link] Having the display server setting the tittlebar instead of the application is a start with server side decoration.Would this mean that my xterm wouldn't be able to print the prompt in the window title?
DRI3000 Posted Feb 12, 2013 12:51 UTC (Tue) by renox (subscriber, #23785) [Link]
>> Having the display server setting the tittlebar instead of the application is a start with server side decoration.
> > Would this mean that my xterm wouldn't be able to print the prompt in the window title?
By default yes.
DRI3000 Posted Feb 12, 2013 19:32 UTC (Tue) by jond (subscriber, #37669) [Link]
And what would the safe bit print? "xterm"? "X terminal emulator"? "/usr/bin/xterm"? "./a.out"?
DRI3000 Posted Feb 12, 2013 18:11 UTC (Tue) by tshow (subscriber, #6411) [Link]
> Having the display server setting the tittlebar instead of the application is a start with server side decoration. Provided there is a 'secure' way for the display server to have such information of course..
So my malicious application requests a window with no decorations and draws its own fake title bar. You have to allow undecorated windows unless you don't want to be able to do things like panels. There's no fixing this without breaking useful functionality.
DRI3000 Posted Feb 12, 2013 21:57 UTC (Tue) by renox (subscriber, #23785) [Link]
That's a good remark.
Either you loose transparent panels or implement some fixed functionality in the compositor (the way the screensaver is implemented in the compositor) or you need a way for the server to be able to distinguish between trusted clients and the other one, I don't know if this is possible..
DRI3000 Posted Feb 13, 2013 8:15 UTC (Wed) by ibukanov (subscriber, #3942) [Link]
> you need a way for the server to be able to distinguish between trusted clients and the other one,
It would be a big oversight in the design of wayland if the server could not do that...
DRI3000 Posted Feb 13, 2013 8:42 UTC (Wed) by renox (subscriber, #23785) [Link]
>> you need a way for the server to be able to distinguish between trusted clients and the other one,
> It would be a big oversight in the design of wayland if the server could not do that...
I don't know if this is a big oversight in Wayland's design or not,
DRI3000 Posted Feb 13, 2013 8:09 UTC (Wed) by ibukanov (subscriber, #3942) [Link]
> You have to allow undecorated windows unless you don't want to be able to do things like panels. There's no fixing this without breaking useful functionality.
One just need to restrict undecorated windows to few trusted applications that are a part of a secure GUI. Done right it would not restrict any useful functionality. For example, a trusted panel still can show status icons and notifications from untrusted applications. And even watching full-screen movies should be possible as window decorations indicating the trust level can appear on any user input.
DRI3000 Posted Feb 13, 2013 10:10 UTC (Wed) by tnoo (subscriber, #20427) [Link]
> One just need to restrict undecorated windows to few trusted applications > that are a part of a secure GUI.
How would this work in a tiling window manager (xmonad, awesome, etc)? These are so great because they don't waste any pixels on useless mostly decorations.
DRI3000 Posted Feb 13, 2013 10:18 UTC (Wed) by renox (subscriber, #23785) [Link]
It wouldn't work of course.
DRI3000 Posted Feb 13, 2013 10:53 UTC (Wed) by ibukanov (subscriber, #3942) [Link]
> How would this work in a tiling window manager (xmonad, awesome, etc)
Some pixels has to be wasted to provide fast visual clues about a trust level. With tiling one can try to color just one edge or a corner of the application in a semi-transparent way to communicate the trust.
Without always present visual clues for passwords one can try to require to press a special trusted key that brings a password-entering GUI that always properly decorate the window. But then one may forget to enter that special key...
DRI3000 Posted Feb 13, 2013 11:42 UTC (Wed) by tnoo (subscriber, #20427) [Link]
Practically, this won't be of much use. Most users don't care about this kind of stuff at all. Who actually checks every time the visual clues for secure connections given in a web browser before entering data?
There are even some people who provide their credentials (for bank or computer accounts) in emails from a "system administrator".
So, frankly, I don't think that the idea you advocate will be of much use in practice.
DRI3000 Posted Feb 13, 2013 12:37 UTC (Wed) by renox (subscriber, #23785) [Link]
> Who actually checks every time the visual clues for secure connections given in a web browser before entering data?
I do, thank you very much. With your reasonment one should remove those visual clues for secure connection? A bad idea.
> So, frankly, I don't think that the idea you advocate will be of much use in practice.
Being useful to those who do these checks is enough to make the feature useful in my opinion.
DRI3000 Posted Feb 13, 2013 12:24 UTC (Wed) by iq-0 (subscriber, #36655) [Link]
> Having the display server setting the tittlebar instead of the application is a start with server side decoration. Provided there is a 'secure' way for the display server to have such information of course..
You'd have to prohibit undecorated windows, transparent windows and full screen windows. All three can be used to create an illusion of a secure input prompt. And even then a basic attack with a maximized window that has in it's content pane something that looks like a secure input window would be enough to fool 80% of the users.
> > That's why security-conscious people invented the ctrl-alt-del keystroke combo that can't be caught by applications and which will always present the system log-on prompt.
The trick is that the special combo can't be grabbed by any normal program *and* that immediately all further input is only tied to a sort of secure input window that is always on top.
If no software can control the mouse or generate fake input for that dialog than it's a pretty sure way of making sure only the person controlling the real input devices is making the input and that that input is only received by the secure input window. And "training" people to enter some magic uncatchable key sequence before entering system credentials helps reduce the risk that they might type it into some malicious window.
This is one of the few things Microsoft did right with UAC. Before granting administrative privileges to a program a use has to press a button in a special popup that isn't visible by other windows programs and which can only be controlled using a few designated input devices (so a malicious program can't click the button itself).
They explicitly don't ask for credentials (so a program faking a security dialog would get no information). And credentials are only required for login and unlock (the "screwup" in this scheme is that a malicious program can pretend to be the login or lock screen and since they no longer train people to always press 'ctrl-alt-del' before login/unlock, there is no way of knowing whether you are typing in the real or a faked variant).
DRI3000 Posted Feb 13, 2013 13:04 UTC (Wed) by renox (subscriber, #23785) [Link]
You're right about the first point but you didn't get my second point: the special keycombo can only work for the native OS's credential, not for your bank's webpage that a trojan could make a look-alike, so that's an useful tool but a very incomplete solution.
DRI3000 Posted Feb 13, 2013 14:17 UTC (Wed) by iq-0 (subscriber, #36655) [Link]
Agreed. But solving that problem is solving the "trusted originator" problem.
This trick could be used to implement a ctrl-alt-del out-of-band validation scheme where a QR-code like tag in a webpage can be used to show a separately loaded website (with very explicit origin information and extra strict settings).
And it would be a light-weight alternative to using a separate device with a camera (and people are free to choose whichever they want to use for the OOB validation).
I'd really like Paypal or my bank to support such an optional validation of a transaction and having an implementation baked-in to the system would make for a very light-weight workflow and be a good deal better than the current variant (and an optional 2nd device out-of-band check for local malware problems and possibly even compromised local networks).
DRI3000 Posted Feb 12, 2013 10:50 UTC (Tue) by lindi (subscriber, #53135) [Link]
Unfortunately that ctrl-alt-del feature is afaik not implemented in any distro.
DRI3000 Posted Feb 22, 2013 9:09 UTC (Fri) by Serge (guest, #84957) [Link]
> Unfortunately that ctrl-alt-del feature is afaik not implemented in any distro.
That would be Alt+SysRq+K (Secure Access Key aka SAK) under text console and/or Ctrl+Alt+Backspace under X. Supported by any Linux distribution. However some distributions turn them off by default.
DRI3000 Posted Feb 22, 2013 9:49 UTC (Fri) by khim (subscriber, #9252) [Link] Ctrl+Alt+Backspace and Alt+SysRq+K perform distinctly different operation: they kill everything in this console and start new session. Ctrl+Alt+Backspace switches to separate context where only "guaranteed secure" set of programs work (and can be used for forensic purposes without immediately killing everything or to just securely lock/unlock workstation's screen).
DRI3000 Posted Feb 22, 2013 19:58 UTC (Fri) by Serge (guest, #84957) [Link]
> Ctrl+Alt+Backspace and Alt+SysRq+K perform distinctly different operation: they kill everything in this console and start new session. Ctrl+Alt+Backspace switches to separate context where only "guaranteed secure" set of programs work
Sure, they work differently, but they solve the same problem. Think about it, what do you actually need this feature for? It won't protect you from virus deleting all files of your user. It won't help you against trojan, looking for your bank account. There's basically ONE problem that it should protect you from.
Imagine a public machine that different users can log in to. It does not matter, is it windows, linux, graphical or text terminal. User just comes, logs in, does the job and logs out, another user comes, etc. Now one of users creates a "fake-login-program" that looks exactly like a login screen, runs that program and goes home. Another user comes, thinks that it's a real login screen, enters login/password, and "fake-login-program" sends them to the author. That's the problem.
And that's the moment when you need those keys. If you're going to log in to a public Windows machine, you first hit Ctrl+Alt+Del, just in case, and then enter login/password. Same when you come to a public Linux machine, whatever you see on a screen, you first hit "Secure Access Key" (if there's something running, it gets killed, getty will respawn), then enter login/password. That's just another (better) solution to the same problem.
> (and can be used for forensic purposes without immediately killing everything or to just securely lock/unlock workstation's screen).
You can Ctrl+Alt+F1...F6, SAK, log in as root and "only guaranteed secure set of programs" will work there for you. Windows just don't have such a simple thing. :)
DRI3000 Posted Feb 23, 2013 15:19 UTC (Sat) by khim (subscriber, #9252) [Link] Think about it, what do you actually need this feature for? Heh. Imagine a public machine that different users can log in to. I don't need to imagine that. This is exactly where we use Ctrl-Alt-Del on Windows the most. It does not matter, is it windows, linux, graphical or text terminal. Yes, it does matter. Very much so. User just comes, logs in, does the job and logs out, another user comes, etc. Sorry, but this is where you conveniently change your usecase to make sure you'll win the argument. Why would I log out? In our case it's pretty beefy test Windows system (actually few Windows systems: Windows XP, Windows Vista, Windows 7, Windows 8, etc) which is shared with many other developers. It's pretty beefy system so we don't log out out of it, but use Ctrl-Alt-Del to lock it instead. When machine is locked (and it's usually locked) I can press Ctrl-Alt-Del to guarantee that I'm at the login screen, log into the system as me (all my programs and windows are where I left them), then, when I'm done with testing, lock the screen again. It's safe because all the places where I enter password are under control of the administrator or me, other people's sessions never see my password. If you're going to log in to a public Windows machine, you first hit Ctrl+Alt+Del, just in case, and then enter login/password. Same when you come to a public Linux machine, whatever you see on a screen, you first hit "Secure Access Key" (if there's something running, it gets killed, getty will respawn), then enter login/password. That's just another (better) solution to the same problem. Is this a joke? Let's compare. Windows "awful solution": Linux's "better" solution: Do you really believe this convoluted dance which you need to perform again if you left the system for the 3 minutes to go to WC is somehow better then Windows approach? You can Ctrl+Alt+F1...F6, SAK, log in as root and "only guaranteed secure set of programs" will work there for you. Windows just don't have such a simple thing. :) It looks like your information is out of date (as usual for Linux pundit). Windows received this ability in Windows Vista which is six year old by now! Before that it was impossible to combine secure Ctrl-Alt-Del with domains which made this approach not all that practically usable. Microsoft fixed it's usability problem and now it's pleasure to use (and quite safe to boot) while Linux pundits continue to preach that their beloved Linux has perfect solution while in fact it's approach is clearly inferior (it may be theoretically slightly more safe, but in practice it's very easy to use it in unsafe way and quite hard to use it in safe way which means that in practice it's worse). Both Linux and Windows continue to evolve and while some places where Linux is better still remain Windows is better in many, many aspects. Ctrl-Alt-Del vs Alt+SysRq+K/Ctrl+Alt+Backspace is one of them. Think about it: why Ctrl+Alt+Backspace is disabled on many [most?] Linux distributions? It's for a reason! This approach is dangerous: it's very easy to accidentally lose your data. Windows's approach, on the other hand, is not just safe - it's pleasure to use!
DRI3000 Posted Feb 23, 2013 22:12 UTC (Sat) by Serge (guest, #84957) [Link]
> I don't need to imagine that. This is exactly where we use Ctrl-Alt-Del on Windows the most.
Good. Many people have a dedicated machine, often more than one, they need neither C-A-Del, nor C-A-BS, nor SAK, they just lock screen and don't worry about such things.
> this is where you conveniently change your usecase to make sure you'll win the argument. Why would I log out?
I explained a more complex case, since I wasn't sure what you actually want. What you have described is a regular switch user (http://i.imgur.com/uhIeO.png) feature that is supported in every distribution around.
To protect from someone creating a screensaver-like tool with fake "Switch User" button, you can configure display manager to autologin on tty1 and run a single program with the large "Switch User" button on it. After that to be safe every time you want to enter the password you press Ctrl+Alt+F1. :)
> Windows received this ability in Windows Vista which is six year old by now!
That's another ability. Under Linux on any virtual console you can run arbitrary "guaranteed secure set of programs", anything you want, not just winlogon dialog.
> Both Linux and Windows continue to evolve and while some places where Linux is better still remain Windows is better in many, many aspects.
Windows is usually better if you got used to it and its bugs. Windows is also often better when it works right out of the box and does exactly what you want. But when you want more, or want to optimize it for your needs, it's easier to configure linux then fight with windows. IMHO, of course.
DRI3000 Posted Feb 23, 2013 23:10 UTC (Sat) by lindi (subscriber, #53135) [Link]
> you can configure display manager to autologin on tty1 and run a single program with the large "Switch User" button on it.
Before we can assess the security of your solution I think you need to first implement it. Before we can assess the usability of your solution I think you need at least a few hundred users. Sorry but the devil is usually in the implementation details :) Also, constantly running a second X server on tty1 wastes memory.
DRI3000 Posted Feb 24, 2013 13:19 UTC (Sun) by khim (subscriber, #9252) [Link] Also, constantly running a second X server on tty1 wastes memory. This waste is limited and should be similar to what Windows wastes for it's own login screen. So that's not a problem. Before we can assess the security of your solution I think you need to first implement it. Before we can assess the usability of your solution I think you need at least a few hundred users. This is a problem. Serge may argue that his solution is perfect (because it's not implemented and thus you can not argue about it's weaknesses) while I argue that it's extremely bad: solution which exists and is used is always more secure on practice then another solution which does not exist and is only imagined by someone.
DRI3000 Posted Feb 25, 2013 10:46 UTC (Mon) by Serge (guest, #84957) [Link]
> Before we can assess the security of your solution I think you need to first implement it.
It's easy. Create user "switcher", configure your DM to autologin it, and set its session to a shell script like this:
while true; do if zenity --info --text 'Switch Session'; then gdmflexiserver; fi; done
Just tested it with Ubuntu and LightDM.
> Before we can assess the usability of your solution I think you need at least a few hundred users.
How are you going to find them? Most people don't need it. Those few who really need it are skilled enough to write one-line-shell-script themselves. :)
> Also, constantly running a second X server on tty1 wastes memory.
Yeah, about 10-15 MB. If that's too much you can replace `zenity` with console `dialog` and run similar script instead of getty. Unlike Windows there're lots of options. :)
DRI3000 Posted Feb 22, 2013 11:16 UTC (Fri) by lindi (subscriber, #53135) [Link]
ctrl-alt-backspace is indeed disabled by default. If I add
Section "InputClass"
to xorg.conf it manages to kill the server. However, a malicious user can run
setxkbmap -option ""
to disable this. It doesn't seem like ctrl-alt-backspace for designed for security.
DRI3000 Posted Feb 22, 2013 19:22 UTC (Fri) by Serge (guest, #84957) [Link]
> However, a malicious user can run: setxkbmap -option ""
That user would probably be you, and this is fine, since you should be able to change your settings. If someone else can run arbitrary commands in your session, Xorg is the least of your problems. :) Those setting will be lost as soon as you log out anyway.
> It doesn't seem like ctrl-alt-backspace for designed for security.
I guess it was not designed for security, but you can still use it for security. :) On the other hand Alt+SysRq+K was actually designed for security.
DRI3000 Posted Feb 22, 2013 19:35 UTC (Fri) by lindi (subscriber, #53135) [Link]
But how do you know that it is your session? That's the whole point of a secure access key. Somebody could have killed your session, logged in and started an imitation of the display manager login window.
DRI3000 Posted Feb 22, 2013 20:11 UTC (Fri) by Serge (guest, #84957) [Link]
> But how do you know that it is your session? That's the whole point of a secure access key.
If somebody logged in, disabled terminate sequence and started login screen emulation, you'll notice, that nothing happens when you press Ctrl-Alt-BS. :) But I agree that "Secure Access Key" (Alt+SysRq+K on Linux) is better for that, and it works both for text and X terminals. It's just some distributions disable Magic SysRq keys, while C-A-BS usually works everywhere during login screen.
DRI3000 Posted Feb 22, 2013 20:26 UTC (Fri) by lindi (subscriber, #53135) [Link]
Well, the fake login prompt can of course be programmed to react to ctrl-alt-backspace.
DRI3000 Posted Feb 12, 2013 11:17 UTC (Tue) by ibukanov (subscriber, #3942) [Link]
> If security relies on user identifying windows and acting based on what they look like, I guess security can't be attained. The pixels are always under attacker's control, one way or other. And I know of no way to sensibly secure, say, policykit's authentication prompt. Anybody can fake that, it's just a window
http://qubes-os.org solved that by not allowing full-screen windows and by using different colors to differentiate windows with different level of trust. As in Qubes all applications runs inside VMs that have no access to the real hardware, applications cannot influence window decorations.
Now, that is slow and drains batteries, but I guess with current hardware it is just impossible to virtualize GPU without performance impact.
> Microsoft chose to train people to look for darkened desktop with a single authorization popup window in middle of it. I've no idea if this is something no other application can fake, or what the point of that is, but it is a tough problem to solve.
It is possible to fake that as long as the OS allows fullscreen windows and does not use hardware buttons to assert administrative tasks. It is sad that MS abandoned that. Ctrl-Alt-Dell is ugly and hard to a press for a disabled person, but they at least could try to use a different key combination.
And even Google have not fully got that. On Android an app can fake the password-protected lock screen and capture a password as Android does not require to press any hardware buttons to unlock it before drawing virtual keyboard. But at least I can press the home key. If that brings me to home screen, then I know that was a fake.
DRI3000 Posted Feb 12, 2013 18:15 UTC (Tue) by tshow (subscriber, #6411) [Link]
> http://qubes-os.org solved that by not allowing full-screen windows and by using different colors to differentiate windows with different level of trust.
Could I make a window that was bigger than the screen, such that all the borders were off screen and the client area effectively filled the visible area? If so, I could draw whatever I wanted on it, and the OS would still think I was a standard client window...
DRI3000 Posted Feb 13, 2013 8:01 UTC (Wed) by ibukanov (subscriber, #3942) [Link]
> Could I make a window that was bigger than the screen,
Barring bugs in Qubes that is not possible. All applications runs inside VMs and their virtual display is smaller than actual screen.
DRI3000 Posted Feb 13, 2013 6:44 UTC (Wed) by nhippi (subscriber, #34640) [Link]
On my Nexus 7, the actual screen is larger than apps can paint to - some of the screen is reserved to the three soft buttons (back/home/app switcher). They could use this area to show the app logo in this area (at least when there is a password input prompt) to make sure users know what app is asking for password.
App store would still need to check that nobody is uploading apps with deceptive icons...
|
|||||||||||||
