| |||||||||||||
People's reaction to this is just stupid.People's reaction to this is just stupid.Posted Nov 19, 2009 17:15 UTC (Thu) by drag (subscriber, #31333)In reply to: People's reaction to this is just stupid. by bfields Parent article: Fedora 12 lets unprivileged users install packages
"""
Malicious local users are rarer than users that can be tricked into
subverting the security of the system unintentionally; a more likely threat
is from a web page or email message that claims to give users something
they want (a game, a faster computer, whatever), if they follow certain
instructions."""
(Log in to post comments)
People's reaction to this is just stupid. Posted Nov 19, 2009 18:21 UTC (Thu) by nix (subscriber, #2304) [Link]
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.)
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.)
People's reaction to this is just stupid. Posted Nov 19, 2009 18:45 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
but something they install in their home directory will not be setuid root
something that the package manager installs may be.
People's reaction to this is just stupid. Posted Nov 19, 2009 23:40 UTC (Thu) by drag (subscriber, #31333) [Link]
Sure.
Having setuid root binaries is a security problem themselves, period, and
People's reaction to this is just stupid. Posted Nov 20, 2009 0:44 UTC (Fri) by gmaxwell (subscriber, #30048) [Link]
At least suid is trivially auditable (find!) and there is decades of established practices, policy, and procedures in dealing with it. I can walk into any library or bookstore and find books on securing systems that cover the subject of SUID binaries and that knowledge and experience is generally portable, not just to all GNU/Linux distributions but across unixes in general.
Eliminating SUID by replacing it with controls buried in a windows-registry like database isn't necessarily an improvement.
People's reaction to this is just stupid. Posted Nov 20, 2009 1:21 UTC (Fri) by drag (subscriber, #31333) [Link] Eliminating SUID by replacing it with controls buried in a windows- registry like database isn't necessarily an improvement.Not always, of course. But I think in the case of policykit and the other *kits it is. This is simply because it should be unnecessary to perform normal desktop operations without resorting to running privileged code under a user's account. These things eliminate that for common cases. I don't think that sudo/su should be eliminated for everything. It should be reserved as a administrative tool and users should only be required to be prompted for the root password or run root code under their account in special cases. I think that in the cases of installing/updating software is such a mundane and everyday event that invoking root password or running code as root is diminishing the security of the typical desktop scenario when a alternative exists. Now for managed desktops then that sort of activity should be forbidden, which is easy enough to accomplish through packagekit/policykit. (also I don't consider storing policy as XML files in directories to be anything like what the negative things the windows registry does...) I do think that having this default spread to _all_ user accounts by default is a bad idea, though.
|
|||||||||||||