> -----Original Message-----
> From: full-disclosure-bounces@xxxxxxxxxxxxxxxxx
> [mailto:full-disclosure-bounces@xxxxxxxxxxxxxxxxx] On Behalf
> Of iDefense Labs
> Sent: Thursday, April 12, 2007 12:54 AM
> To: vulnwatch@xxxxxxxxxxxxx;
> full-disclosure@xxxxxxxxxxxxxxxxx; bugtraq@xxxxxxxxxxxxxxxxx
> Subject: [Full-disclosure] iDefense Security Advisory
> 04.11.07: Apache HTTPD suEXEC Multiple Vulnerabilities
>
> Apache HTTPD suEXEC Multiple Vulnerabilities
>
> iDefense Security Advisory 04.11.07
>
> Apr 11, 2007
>
> I. BACKGROUND
>
> The suexec binary is a helper application which is part of the Apache
> HTTP server package. It is designed to allow a script to run with the
> privileges of the owner of the script instead the privileges of the
> server. More information about the suexec utility can be found at the
> following URL.
>
>
>
> II. DESCRIPTION
>
> Local exploitation of multiple vulnerabilities within Apache Software
> Foundation's suexec utility could allow an attacker to execute
> arbitrary code as another user.
>
> 1) Path Checking Race Condition Vulnerabilities
>
> One race condition occurs between the obtaining the current directory
> and changing to that directory. Another race condition occurs between
> changing to a directory and checking that the directory is not a link.
> The directory structure may change between each of these operations,
> which can lead to the lstat() being performed on an arbitrary
> directory
> chosen by an attacker. These may be exploited with by
> renaming a parent
> directory, or by using symbolic links.
>
> A third race condition occurs between the final symbolic link
> check and
> executing the target binary. The directory structure may
> change between
> these calls, rendering the symbolic link check ineffective.
>
> 2) Path Checking Design Error Vulnerabilities
>
> The suexec utility uses a strncmp() to check whether the current
> directory is a sub-directory of the document root directory.
> This check
> will succeed in situations where there exists a directory which begins
> with the same sequence, but contains extra content. For
> example, if the
> document root is "/var/www/html", the test will also succeed for
> "/var/www/html_backup" and "/var/www/htmleditor". A correct test would
> also perform a check that the next character is a trailing
> null-terminator or directory separator.
>
> A check performed does not verify whether a path to the CGI
> script (cmd)
> is a regular file or not. If the path is pointing at a sub-directory
> owned by the appropriate user and group, and the parent directory is
> owned by the appropriate user and group, it will be accepted.
>
> 3) Arbitrary Group Id Input Validation Vulnerability
>
> Due to a design error, the suexec binary permits any combination of
> user/group values taken from command line parameters even if the user
> is not a member of the specified group. This may be exploited in
> combination with other vulnerabilities if the /proc file system is
> mounted. Each time suexec drops its privileges and changes its UID and
> GID, all files and directories under /proc/{PID} change their owner to
> the corresponding values. As the suexec process changes its
> UID and GID
> unconditionally, creating arbitrary UID and GID owned files
> is trivial.
>
> III. ANALYSIS
>
> Exploitation of these vulnerabilities would allow a local attacker to
> execute arbitrary code with the privileges of another user.
>
> In order to exploit this vulnerability, the user must already have
> access to execute the suexec binary. The suexec binary is only able to
> be executed by the same user as the web server, typically
> user 'httpd',
> 'apache' or 'nobody'. It may be possible to gain access to
> this user by
> exploiting a CGI program, PHP script or other program on the server.
>
> The binary also limits the users it will execute code as to
> those which
> have user and group IDs greater than or equal to AP_UID_MIN and
> AP_GID_MIN values respectively. These values are compiled into the
> executable.
>
> These factors somewhat mitigate the severity of the problem.
>
> IV. DETECTION
>
> iDefense has confirmed the existence of these vulnerabilities in the
> suexec binary distributed with the version 2.2.3 of the
> Apache httpd in
> Red Hat Inc.'s Fedora Core 4. This distribution is not
> vulnerable in the
> default configuration, as exploitation requires additional,
> but common,
> configuration changes to be made to the system.
>
> It is suspected that all previous versions of suexec are vulnerable,
> including the 1.3.x versions.
>
> V. WORKAROUND
>
> If the suexec binary is not required for normal operation, remove the
> set-uid bit from the file as shown below.
>
> # chmod -s /path/to/suexec
>
> VI. VENDOR RESPONSE
>
> The Apache Software Foundation HTTPD team declined to address the
> vulnerabilities and instead provided the following vendor statement.
>
> "The attacks described rely on an insecure server configuration - that
> the unprivileged user the server runs as has write access to the
> document root. The suexec tool cannot detect all possible insecure
> configurations, nor can it protect against privilege "escalation" in
> all such cases.
>
> It is important to note that to be able to invoke suexec, the attacker
> must also first gain the ability to execute arbitrary code as the
> unprivileged server user."
>
> VII. CVE INFORMATION
>
> The Common Vulnerabilities and Exposures (CVE) project has
> assigned the
> name CVE-2007-1741 to this issue. This is a candidate for inclusion in
> the CVE list (), which standardizes names for
> security problems.
>
> VIII. DISCLOSURE TIMELINE
>
> 02/08/2006 Initial vendor notification
> 10/06/2006 Second vendor notification
> 03/28/2007 Third vendor notification
> 03/28/2007 Initial vendor response
> 04/11/2007 Public disclosure
>
> IX. CREDIT
>
> The discoverer of this vulnerability wishes to remain anonymous.
>
> Get paid for vulnerability research
>
>
> Free tools, research and upcoming events
>
>
> X. LEGAL NOTICES
>
> Copyright (c) 2007 iDefense, Inc.
>
> Permission is granted for the redistribution of this alert
> electronically. It may not be edited in any way without the express
> written consent of iDefense. If you wish to reprint the whole or any
> part of this alert in any other medium other than electronically,
> please e-mail customerservice@xxxxxxxxxxxx for permission.
>
> Disclaimer: The information in the advisory is believed to be accurate
> at the time of publishing based on currently available
> information. Use
> of the information constitutes acceptance for use in an AS IS
> condition.
> There are no warranties with regard to this information. Neither the
> author nor the publisher accepts any liability for any direct,
> indirect, or consequential loss or damage arising from use of, or
> reliance on, this information.
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter:
> Hosted and sponsored by Secunia -
>
