| |||||||||||||
People's reaction to this is just stupid.People's reaction to this is just stupid.Posted Nov 19, 2009 18:21 UTC (Thu) by nix (subscriber, #2304)In reply to: People's reaction to this is just stupid. by drag Parent article: Fedora 12 lets unprivileged users install packages
The attack vector is obvious.
A local root hole is found in an obscure piece of software packaged by Fedora (perhaps one that, in violation of Fedora policy, runs a daemon on installations; perhaps one with a nasty bug in its installation scripts). The package is obscure, so fixing it takes a relatively low priority. This could be *any* such package: the only real constraint is that it should be obscure enough that most Fedora systems don't have it installed (and there are thousands of such packages). If the package is obscure, it's likely that it doesn't get audited much, so blackhats may very well know of holes in such packages that whitehats don't: so the window here may be very wide indeed. (In current Fedora, this is pretty unimportant, as the package is rarely installed so few people are vulnerable.)
An arbitrary code execution vulnerability is found in Firefox or one of the libraries it uses. These often take a while to fix because FF is a monstrous pig and because of the Mozilla trademark policy requiring signoff (IIRC Fedora has Firefox, not a renamed package).
Now an attacker can exploit the latter vulnerability (probably served via an ad server's rotation on a totally innocent webpage) and then use the former to get root with high probability, probably almost undetectably.
Not good.
(Note: I'm not any sort of security specialist. If *I* can generate this scenario with a few seconds' thought, actual malicious attackers surely can.)
(Log in to post comments)
People's reaction to this is just stupid. Posted Nov 19, 2009 20:03 UTC (Thu) by drag (subscriber, #31333) [Link] If a attacker gains access to your local account then they can execute arbitrary code in your user's account and end up doing pretty much whatever then wnt. So, yes, if they can (for example) inject a command in your bashrc script that will command packagekit to install a package. Then if they find a vulnerable package that installs and automatically launches a vulnerable service that runs as root then the attacker could use that to gain root access.Yes, that is certainly a possibility. However.... Here is another potential attack. Imagine your attacking a typical Linux desktop user that has sudo configured to do things like mounting drives or configuring the network or updating their software. Your trying to attack a system like that and you've managed to gain access to their account through something like a vulnerability in the flash plugin. All you have to do is just stick a job into the user's account to run 'if sudo ls > /dev/null; then sudo ~/.run_rootkit;done' every few seconds or so. I'd say that over a period of a day or two the user would of certainly done 'sudo ifconfig' or 'sudo apt-get update' or some such thing. Thus giving the attacker unlimited access to the root account. Of course attackers would probably just go for the most generic attack and install a keylogger or something. ---------------------- Like I said before having a 'admin' password separate from root and the user password is probably a good idea. Maybe not, I don't know. It would certainly address most concerns coming from most people. ----------------- I think that the current #1 threat to Linux systems is users setting up OpenSSH access with weak passwords and attackers guessing those passwords through brute force. Think about that in conjunction with 'sudo'. :)
People's reaction to this is just stupid. Posted Nov 19, 2009 21:17 UTC (Thu) by nix (subscriber, #2304) [Link]
Your assumption that the ability to run 'sudo yum update' implies the
ability to run 'sudo ls' or 'sudo sh' is incorrect. (Just because Ubuntu sets it up that way doesn't mean it's the only way, or even a particularly good one.)
At least sudo can be configured to ask you for a password (at intervals or
In any case, the existence of one security hole isn't a reason to allow
People's reaction to this is just stupid. Posted Nov 19, 2009 23:17 UTC (Thu) by drag (subscriber, #31333) [Link] """ Your assumption that the ability to run 'sudo yum update' implies the ability to run 'sudo ls' or 'sudo sh' is incorrect. (Just because Ubuntu sets it up that way doesn't mean it's the only way, or even a particularly good one.) """My assumption is based on the reality of what is a seems to be a acceptable default configuration for distros. The 'status quo', so to say. If you can lock down sudo then I can change whatever I want with package kit and it is impossible to make a good comparison. """ At least sudo can be configured to ask you for a password (at intervals or every time), and as it's setuid it's relatively hard for an attacker running as the user to spy on the user's keystrokes as he types it in. So elevation to the user does not necessarily mean you can get to root that way.""" Yes. The usual default configuration is to allow sudo access by prompting for a password. This is what I am talking about. And it allows you to re-run sudo without a password for a period of time. My example exploit depends on this behavior. If you run sudo from one console then that gives unlimited root access to any sudo command without prompting for a password for a period of time for every instance of that user's account. Of course this is configurable, but remember the dispute is about default configurations. I am not sure how it is with Fedora, but people don't seem to have a problem with Ubuntu and I think it's the same. """ In any case, the existence of one security hole isn't a reason to allow another one to continue to exist! """ Sure... But you have to realize that the use of things like packagekit and policykit is to eliminate the need for things like sudo for typical desktop activities. I am of the opinion that a desktop that does not require running root code under a user's account as a part of normal everyday activities is superior to one that does. I am looking forward to the day that a user is able to perform every common function on the desktop without requiring root access or running root code under their account and this is a big step in that direction. No distro should ship with sudo enabled for anything! Sudo and su should be reserved for administrators and experts. Expecting normal users to be able to use these things safely is asking too much. And using gtksudo (and similar things) to run GUI applications entirely as root under your account is a huge security hole in itself. Probably the thing should ask for a admin password or something like that, but I think that asking for a user's password is security theater and asking for a root password is just a plain bad idea.
People's reaction to this is just stupid. Posted Nov 20, 2009 2:29 UTC (Fri) by khc (subscriber, #45209) [Link] If you run sudo from one console then that gives unlimited root access to any sudo command without prompting for a password for a period of time for every instance of that user's account.That is not true (at least by default) in ubuntu. If I give sudo password in one terminal, running it again *in another terminal* requires me to enter the password again.
People's reaction to this is just stupid. Posted Nov 20, 2009 2:36 UTC (Fri) by foom (subscriber, #14868) [Link]
That does nothing for security, however. There is no security barrier between two terminals running
as the same UID: The second terminal is just a ptrace() away from making the first terminal run sudo for it...
People's reaction to this is just stupid. Posted Nov 20, 2009 12:26 UTC (Fri) by hppnq (guest, #14462) [Link] You can't ptrace() sudo, and you can't run sudo with suid if the parent is traced. It is not that stupid. ;-)(Obviously, if you have a terminal you have other ways to snoop passwords.)
|
|||||||||||||