[driven]

Found this today, thought that it might be helpful.

---
(reposted without permission)


Security Watch: Could sudo Compromise Mac OS?

Top Threat: sudo Root Compromise
Executive Summary
Name: sudo Root Compromise
Affects: Mac OS X 10.3.x confirmed, probable on all platforms running sudo

Details

A Trojan horse program run by a user with admin privileges can utilize the sudo utility program to execute as the root user.

The original report on this vulnerability described it as a problem with Mac OS X, but a subsequent report indicates that it applies to any platform on which sudo is run.

The problem is tied to default settings for sudo: Under which a five minute grace period exists after running it during which sudo may be run without again providing a password. The execution context for sudo is system-global for the user, and not tied to a particular terminal session. Finally, the log file used by sudo (/var/log/system.log) is readable by anyone in the admin group.

Given these settings, the Trojan program waits for changes to be written to the /var/log/system.log and looks for entries that would elevate the user context of the Trojan. It then has five minutes to execute sudo with any command to elevate its own privileges.

How to avoid it:

According to the initial report, any of these steps will correct the problem:

* Add the following lines to the /etc/sudoers file, in the "Defaults" section:
Defaults:ALL !syslog
Defaults:ALL logfile=/var/log/secure.log This redirects the sudo logs to /var/log/secure.log (which has the appropriate permissions and is a more appropriate log for authentication components)
* Add the following line to the /etc/sudoers file, in the "Defaults" section:
Defaults:ALL timestamp_timeout=0 This removes the password grace period and forces the user to authenticate every time sudo is run.
* Add the following line to the /etc/sudoers file, in the "Defaults" section:
Defaults:ALL tty_tickets This limits the sudo grace period to individual ttys (terminal sessions) and makes it much more difficult for a Trojan to compromise the system using this technique.

The author of the advisory recommends that you use the Visudo tool to edit the /etc/sudoers file. This utility will check your syntax, keeping you from corrupting your file.

[Big Mac]

This was posted on Slashdot days ago, and I was waiting for it to finally be discussed on the forums. Apple is apparently not concerned about the potential security risk, and the reason that is reportedly given for that attitude is pretty humorous: Administrators are supposed to not run untrusted code. As the authors of the piece point out, many of us use our admin account as our regular account (rightly or wrongly), and regular users can't be expected to know 100% of the time what is or is not malicious code. Apple's advice is essentially useless. At least the article provides a number of methods that may be used to close the hole.

[driven]

At least it's still better than Windows. :-) ( Where everyone is an administrator and all code is friendly. <gasp> )

[JKT]

Probably I am misunderstanding but to achieve this, surely you would have had to install the trojan via your admin privileges in the first place? In other words, this exploit seems a little meaningless - you have already given the trojan permission to install and execute (at which point it could be programmed to do anything) so why would it then need to once more regain those privileges using this exploit?

Or could the trojan be installed and executed without admin privileges?

[JLL]

Originally Posted by JKT

Probably I am misunderstanding but to achieve this, surely you would have had to install the trojan via your admin privileges in the first place? In other words, this exploit seems a little meaningless - you have already given the trojan permission to install and execute (at which point it could be programmed to do anything) so why would it then need to once more regain those privileges using this exploit?

Or could the trojan be installed and executed without admin privileges?

It can't read the system.log without admin privileges. An app run by the admin user should be able to read it, but as you say, the admin user will have to install it himself.

[Millennium]

Originally Posted by driven

At least it's still better than Windows. :-) ( Where everyone is an administrator and all code is friendly. <gasp> )

Actually, non-admin users do exist on Windows. However, the Windows folks make it as difficult as they possibly can to run as a non-admin; the preference is somewhat buried in the control panels, and (unlike OSX) they offer no opportunity to authenticate with an admin password when a non-admin tries to do something; unless you're already logged in as an admin it Simply Doesn't Work.

It also doesn't help that instead of "Administrator" and "User", as they're called in OSX, Windows calls them "Administrator" and "Limited User", terminology which is certain to dissuade people from running in such a state. People need to get over the idea that permissions are a useless means of protecting the user from themselves, and terms like "Limited User" do not help this.

Both OSX and Windows need to do work to make it easier for ordinary home users to run as non-admins. OSX is far ahead of the game as far as this is concerned, in that it allows you to authenticate to perform most Admin-only tasks without having to actually switch users. The result is much more usable than the Windows alternative, where you just hit a brick wall. However, even OSX needs to do some work. In particular, they need to make sure that the very first user created after a new install is a non-admin, but there are still a few situations left where they need to offer the authentication dialog so that users can do what's needed without switching accounts.

[driven]

I fully realize that Windows has non-admin users, however non admin users are rarely used even in corporate settings. (In spite of Microsoft's best practices documentation.)

In fact, XP Home by DEFAULT makes everyone an admin. Yuk.

I would contend that if Windows users DID run as a limited user (or even a Power User) that the security holes would be minimized.

As to the first question posed here:
Yes: A regular user could install the program that would exploit this bug. The harmful software would run in the user's context and monitor the system.log file looking for a particular entry that indicated that SUDO was used. Once it is used it takes advantage of the SUDO grace period to log in as administrator and install something far more harmful.

The suggestions given in the article are good ones.

[Chuckit]

You know, when I first saw the title "Sudo is a potential security risk," I thought somebody was making fun of Millennium.

[Millennium]

Originally Posted by driven

I would contend that if Windows users DID run as a limited user (or even a Power User) that the security holes would be minimized.

Only to a limited degree. Windows has plenty of security holes through which malware can enter or leave (i.e. spread from) a computer, whereas OSX has far fewer (no unpatched holes known at present, if I'm not mistaken). However, once malware actually entered a computer, it would be limited in scope and could therefore do far less damage.

The real problem is that Windows needs to make it easier to run as a non-admin user, by offering authentication dialogs for sensitive actions rather than simply disallowing them until you switch users. These dialogs are a major usability benefit, and they provide that benefit in a way that doesn't compromise security since the need to authenticate is preserved. OSX doesn't quite have this perfect yet, but they had some functionality which did this in 10.0 and they have improved it greatly since then.

[Detrius]

You know, if all apps worked by using sudo for authentication, the guys in this thread would be thrilled to death:

http://forums.macnn.com/90/mac-os-x/248100/help-me-get-apple-fix-stupid/post/2480048/


BTW, this is OLD news, as in probably years or decades old. This has ALWAYS been considered a security risk of sudo, but sudo is still around and preferred over su, as su gets you a permanent root shell.

[theolein]

I think the idea behind strengthening sudo is a sound one, even though it only applies to admin users, but quite a lot of Mac OSX users run as admin even though they have no real need to do so.

[JLL]

Originally Posted by driven

Yes: A regular user could install the program that would exploit this bug. The harmful software would run in the user's context and monitor the system.log file looking for a particular entry that indicated that SUDO was used. Once it is used it takes advantage of the SUDO grace period to log in as administrator and install something far more harmful.

No a regular user can't read system.log

[OreoCookie]

This is really old, old news. That's why in certain Linux distros and FreeBSD, you have to manually select sudo to have it installed.

It's obviously a security vs. convenience issue, so you can discuss it either way. You can change that in the sudoers file, though.

[Millennium]

That's part of it, but OSX's configuration of sudo is not the most secure thing in the world, either. It's certainly an innovative means of configuring it; the ability to create a while class of users who can authenticate into full root permissions is not entirely new, but it has never been common in the Unix world. Then again, there are reasons for that, such as the fact that there are now multiple accounts which can become root if they are compromised (this was a fairly common complaint from people who had switched from Unix in the early days of OSX). In most Unix configurations, sudo only works for particular applications.

My guess is that Apple will implement the secure.log fix and be done with it, though I'd like to see them implement the tty_tickets solution as well.

[proton]

Originally Posted by Millennium

The real problem is that Windows needs to make it easier to run as a non-admin user, by offering authentication dialogs for sensitive actions rather than simply disallowing them until you switch users. These dialogs are a major usability benefit, and they provide that benefit in a way that doesn't compromise security since the need to authenticate is preserved. OSX doesn't quite have this perfect yet, but they had some functionality which did this in 10.0 and they have improved it greatly since then.

Well actually Windows (2000 and later) does offer this functionality (sort of).

Hold down shift while you right click on an application in Windows 2000/XP/2003 and you'll see an option to "Run As". This lets you run that application as another user, usually an administrator. While it's not the same as OS X offering up front to switch to an admin user for the application, it's certainly better than requiring a login/logout, if only for savvy users.

- proton

[Millennium]

Originally Posted by proton

Well actually Windows (2000 and later) does offer this functionality (sort of).

Hold down shift while you right click on an application in Windows 2000/XP/2003 and you'll see an option to "Run As". This lets you run that application as another user, usually an administrator. While it's not the same as OS X offering up front to switch to an admin user for the application, it's certainly better than requiring a login/logout, if only for savvy users.

Interesting. That's a feature they need to advertise better.