OSX - trojan apps can bypass authentication controls and gain root privilages
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.