6

Contrary to most other posts this is really a brainstorming post in the sense that the idea is not yet fledged out, and that I think a sane discussion could lead to something interesting.
The problem: Linux/Unix is a nice system in that it separates root-access from client-access. In theory an exploit for a program running in user-mode does not give access to the root-system. In theory...
I regularly use 'sudo' to perform administrative tasks inside Konsole, and once an exploit (inside _any_ exploitable program) got into my user-environment nothing prevents it from sniffing the sudo-password and hence get full root-access to my machine.
Proposed solution (inspired by WindowsNT): Whenever asking for my password I have to press a key-combination that can't be intercepted by user-programs (like switching to another console with crtl+alt+Fx) and give my password in this "safe"-mode. In this safe-mode the name (+location...) of the program etc should be displayed at the same time (to be sure it's really "my" program that is asking for the password.

I agree that a global solution (not linked to KDE) would be the best, but I think that even on its own KDE can do quite a lot. Ideally KDE would be the driving force for a new protocol (for instance by integrating new techniques into Konsole, KWalletManager, etc.)

Edit: KDM is actually a really good candidate for this. Currently It's extremely easy to steal passwords by providing a fake login-screen.

Edit2: Here are scenarii that lead to an exploited machine:
Scenario 1:
User Toto believes Linux is secure and browses with his Firefox browser without paying attention. Due to an unpatched security hole (the devs already pushed a new version, but Toto did not yet update) a malicious program gets access to his system.
At this point the attacker can see all his documents, but this is a know risk, we can't really avoid that.
Just seconds later Toto sees the upgrade button that informs him that Firefox is insecure and that he should perform an update. KSudo (or PolicyKit) nicely asks him to enter his administration password to replace the broken Firefox.
Unfortunately the malicious script is listening to all X events and retrieves the password. It then uses sudo to install a whole root-kit and the whole machine is powned.

Scenario 2:
A University uses Linux/KDE. A malicious user creates a simple application that mimicks the KDM-login manager. It then captures the passwords and sends them to his hotmail-account.
This might not always lead to a hacked system (only if an administrator logged on the machine), but this is still an extreme security leak.

The problem is hence that users provide their secure passwords in an insecure environment. I propose that KDE should provide (maybe in combination with changes to X?) a secure password area that can only be reached by a secure channel (let's say an intercepted key-combination).

Here are two screenshots:

and


The idea is that passwords (and not just administration passwords) are given in a secure area that is owned by a different user that the currently running one. In other words: the password area should not be part of the default X-environment. Maybe this would need changes to X, but still. Also: the key-combination to enter the secure environment should always be intercepted by the kernel or X.

Note: for the linux console the same problem exists (but they only discuss it for the login process) and here is their solution:
SAK (lwn.net)

I think it's a good idea (and it's rather surprising how many really useful ideas that would really improve KDE here aren't getting too many votes while secondary things like adding more bright colors and other pretty stuff get dozens. I hope developers won't be just "democratic" and use some good sense and "seriousness" besides following "popular will") but I don't see how can it be effective being KDE just a desktop environment, there are many other ways to access the system, and hence I don't know if voting; I sure would if this were some golbal OS security stuff forum or about whatever that would make your idea really effective. Perhaps you should propose it somewhere else? I don't know.

If you're paranoid, you could always switch to the console (Control+Alt+Fx) and do your task from there

Well...
First: In order for the program to execute, even in your area, it has to be, "Executable". If you have found the program to actually set the executable bit, I presume you know the program wasn't supposed to be there in the first place (why would it? Programs you purposely install tend to end up in /usr somewhere...).
Second: kdesu already tells you what program is actually asking for your root password.

Madman wrote:Well...
First: In order for the program to execute, even in your area, it has to be, "Executable". If you have found the program to actually set the executable bit, I presume you know the program wasn't supposed to be there in the first place (why would it? Programs you purposely install tend to end up in /usr somewhere...).

I'm talking about security exploits in programs. For instance (and I'm just taking KDE-programs here, cause it is a KDE forum): gwenview, konqueror, okular, ...
Once one of these programs is exploited it has access to the complete user-environment. And then adding malicious code is easy. A very easy way (but easy to detect) would be adding a script in .kde4/env. I don't think many users even know that scripts are executed there. And there are way more sophisticated attacks.

Second: kdesu already tells you what program is actually asking for your root password.

yes. and that is nice. But nothing prevents malicious code to replace the code inside the kdesu program. After all it runs in user-mode.

Alec wrote:If you're paranoid, you could always switch to the console (Control+Alt+Fx) and do your task from there

Obviously that's not what one wants to do. (and I see your smilie). But still, there are some issues that are not obvious.
Once an exploit got access to my system it can execute any code and modify my complete environment. Nothing prevents it from inserting a fake-bash so that I'm running my system administration inside the fake bash. It can then intercept calls to 'sudo' and get the password this way. "sudo" is evil from this perspective. The only secure way would be to log in as root. But we know that root-logins are not optimal either.

So the whole system should also work with console programs. I suppose it should replace 'sudo' as well. Let's say ssudo and I have to type the password in another tty.

Still I think it's not just a system problem (writing this tool should not be too hard, and maybe I'm even going to give it a try), but there should be good UI integration. Starting with kdm.
Currently it's very easy to write a kdm-replacement that captures passwords. Years ago we had a similar program on one of the computers at my university. It was detected because the mail with all the passwords was somehow too big (or something similar) and got the attention of one of the admins.

m talking about security exploits in programs.

Good God! Vulnerabilities in KDE? I hope not! :P

A very easy way (but easy to detect) would be adding a script in .kde4/env

I just checked this: though .kde4/env didn't work for me (it prevented me logging in, for whatever reason), putting a script in .kde4/Autostart without the execute bit set didn't execute it: it actually opened the script file.

Madman wrote:

m talking about security exploits in programs.

Good God! Vulnerabilities in KDE? I hope not! :P

A very easy way (but easy to detect) would be adding a script in .kde4/env

I just checked this: though .kde4/env didn't work for me (it prevented me logging in, for whatever reason), putting a script in .kde4/Autostart without the execute bit set didn't execute it: it actually opened the script file.

yes. they probably need to be set to be executable. But that's not too difficult to do. My point is, that users won't see these executables.
Do you suggest that users should simply not (be allowed to) have executable programs in their home? That would solve these simple attacks, but I'm pretty sure there are many ways to execute code without actually being executable. And some users actually use this feature. I regularly provide my "clients" with scripts for automated tasks which they have on their desktop, etc.

I think that KDE is moving to using PolicyKit which I think means that applications register a pre-defined chunk of code which will need to run as root. PolicyKit will only escalate for that particular registered function.

This means it is much harder for someone to exploit a hole in a particular application. PolicyKit would not let it elevate the code which was injected.

Well, I think that's how it works anyway. That is also why there is not much root level access in the systemsettings app. Each part needs to register what code they want to elevate via PolicyKit and developers know to pay special attention to that code.

http://en.wikipedia.org/wiki/PolicyKit

I think sudo is the broken part of the equation at the moment.

mikedee wrote:This means it is much harder for someone to exploit a hole in a particular application. PolicyKit would not let it elevate the code which was injected.

Not at all. As long as the password is entered under X nothing prevents any exploit to play man-in-the-middle and capture the password. It just means that a bug in these applications won't automatically lead to a powned system.

I think sudo is the broken part of the equation at the moment.

Only if the underlying programs are buggy. But that's not the point here.

The _real_ big problem is, that users use the same account for admin-tasks and while running unsecure programs (like Firefox, Konqueror, Okular, etc.). Any bug in these applications could lead to an exploited user-environment, and if the user then performs administration tasks he will, at some point, reveal his password.

I will edit my first post to make this point more clear.

Maybe the real answer is not to rely on passwords at all. Maybe use one-time USB keys or passwordless authentication and never use sudo. It looks like truly stopping password sniffing would require a lot of extra effort and hardware. We all buy keys for our cars and houses so why not for our computers? Nobody would protect their car with a password.

Combine that with removing sudo and using PolicyKit for all elevation, I think it would be a fairly secure system. Add in AppArmour / SELinux and the initial exploit would be much harder since firefox would not be allowed to write to ~/Autostart in the first place.

mikedee wrote:Maybe the real answer is not to rely on passwords at all. Maybe use one-time USB keys or passwordless authentication and never use sudo. It looks like truly stopping password sniffing would require a lot of extra effort and hardware. We all buy keys for our cars and houses so why not for our computers? Nobody would protect their car with a password.

Combine that with removing sudo and using PolicyKit for all elevation, I think it would be a fairly secure system. Add in AppArmour / SELinux and the initial exploit would be much harder since firefox would not be allowed to write to ~/Autostart in the first place.

USB-keys, fingerprint-authentication, etc. are all possible improvements, but you would still need a "secure" area for messages. Suppose your user-environment is infected and you type 'sudo xyz' inside Konsole. Where it asks you to insert a one-time usb-key. Nothing forbids the malicious code to replace your 'sudo xyz' with 'sudo install-rootkit' (while still showing you your expected output).
However the malicious code would not be able to modify the secure area.
Even if such a secure area is not yet in place I think that KDE programs can start preparing for it (in the worst case let KDE intercept the "secure shortcut" for now). Now that graphics drivers are inside the kernel it's just a matter of time before the kernel can send messages in front of the X windows (at least I hope so).

I fail to see how this proposal stops people from making a dummy program that mimics the behavior of the authentication system.

rouge568 wrote:I fail to see how this proposal stops people from making a dummy program that mimics the behavior of the authentication system.

The key to solve intercepting passwords is to provide a non-interceptable keyboard-shortcut. After having typed (for instance) ctrl-alt-pause the user switches into secure area (controlled by a root-program) where she can safely enter the password without fearing password-interception.

Edit: The non-interceptable shortcut and the secure area must be implemented on lower levels (xorg, kernel), but in theory they are small. And even if they do not exist yet KDE can start preparing for them. For now just KDE could intercept the "non-interceptable" shortcut.

flo wrote:The key to solve intercepting passwords is to provide a non-interceptable keyboard-shortcut. After having typed (for instance) ctrl-alt-pause the user switches into secure area (controlled by a root-program) where she can safely enter the password without fearing password-interception.

Edit: The non-interceptable shortcut and the secure area must be implemented on lower levels (xorg, kernel), but in theory they are small. And even if they do not exist yet KDE can start preparing for them. For now just KDE could intercept the "non-interceptable" shortcut.

And what if I remotely connect through the VNC? Does that mean I can not assume root privileges?