Date: Wed, 06 Apr 2005 16:26:05 -0400
From: "KF (lists)" <kf_lists@...italmunition.com>
To: bert@...as.net
Cc: bugtraq@...urityfocus.com
Subject: Re: OSX - trojan apps can bypass authentication controls and gain
 root      privilages


Explain to me how this is a MacOS specific bug? I can duplicate this 
behavior on my debian linux machine.
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@...as.net 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.
>
>
>
>
>
>
>
>
>  
>

Powered by blists - more mailing lists