This is fairly generic to anything using sudo with out the included config options you mentioned below, or am I missing something? There is no need to single out apple.
If you have the ability to introduce a trojan into an admin level account you appear to have other issues on your hands. =]
I think this advisory is more suited for a how to securely configure sudo FAQ.
-KF
bert@xxxxxxxxx wrote:
OSX Root Compromise 04/05/2005
Summary: OSX can be root compromised by a trojan application. The trojan application does not require explicit user authentication to elevate its privileges to root, nor does the root account need to be enabled. The Trojan application must be run from an account that is in the admin group, which is the default for the first account created and the context in which most users run. Once executed, the trojan application must only wait until the user leverages the sudo utility, either at the command line or by another application that leverages sudo to elevate it's privileges.
A demonstration app is available at www.adbas.net/software/rooted.dmg
Status: The issue has been reported to Apple. Apple does not feel this is an issue as "Administrators should not run arbitrary software." While it is true that users should be cautious of running untrusted code, this answer is unacceptable. Administrators are required to authenticate actions to the core operating system. This vulnerability allows applications to bypass this requirement by "piggy-backing" off an unrelated authorization event.
Versions Affected: OSX 10.3.x confirmed, OSX 10.2 probable
Issue: There are 3 factors that allow this to be possible:
1) sudo is by default, configured to allow a 5 minute password time out. This means that subsequent use of sudo, within this grace period does not
require a password for authentication.
2) sudo is by default, configured to be global, meaning its session is not tied to a tty but rather to only the user and time.
3) sudo writes its entries to /var/log/system.log, which, by default, is readable by anyone in the admin group.
All the trojan application needs to do is monitor the /var/log/system.log file for sudo entries for the user who executed the trojan. Once an entry is found, that is within the timeout grace window, the trojan can then elevate it's privileges to root by simply executing sudo "anycommand".
Fixing: Any of following changes to sudo will correct the problem.
To redirect sudo logs to /var/log/secure.log (which has the appropriate permissions and is a more appropriate log for authentication components), add the following lines to the /etc/sudoers file, in the "Defaults" section:
Defaults:ALL !syslog Defaults:ALL logfile=/var/log/secure.log
To remove the password grace period which will force the user to authenticate every time sudo is called, add the following line to the /etc/sudoers file, in the "Defaults" section:
Defaults:ALL timestamp_timeout=0
To limit sudo password grace period to individual ttys, instead of global, add the following line to the /etc/sudoers file, in the "Defaults" section:
Defaults:ALL tty_tickets
Redirecting sudo's logging and containing sudo sessions to individual ttys, in the authors opinion, provides the best balance of functionality and security.
Please ensure that you use the visudo tool to edit the /etc/sudoers file. This utility will check your syntax, keeping you from corrupting your
file. By default, visudo uses vi as its editor.
