Back to list
OSX - trojan apps can bypass authentication controls and gain root privilages
Apr 06 2005 04:06AM
bert adbas net
Re: OSX - trojan apps can bypass authentication controls and gain root privilages
Apr 06 2005 08:26PM
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
bert (at) adbas (dot) net [email concealed] wrote:
>OSX Root Compromise
>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
>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
>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".
>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"
>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:
>To limit sudo password grace period to individual ttys, instead of global,
>add the following line to the /etc/sudoers file, in the "Defaults"
>Redirecting sudo's logging and containing sudo sessions to individual
>ttys, in the authors opinion, provides the best balance of functionality
>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.
[ reply ]
Copyright 2010, SecurityFocus