Re: OSX - trojan apps can bypass authentication controls and gain root privilages

["KF (lists)" <kf_lists () digitalmunition com>]

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 () adbas 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.
>
>
>
>
>
>
>
>
>