Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

   


   


   

















      :: Security-alerts
Security-Alerts mailing list archive (security-alerts@yandex-team.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[security-alerts] FW: Apache HTTPD suEXEC Multiple Vulnerabilities



> -----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
> http://labs.idefense.com/intelligence/vulnerabilities/
> 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.
> 
> http://httpd.apache.org/docs/2.0/suexec.html
> 
> 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 (http://cve.mitre.org/), 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
> http://labs.idefense.com/methodology/vulnerability/vcp.php
> 
> Free tools, research and upcoming events
> http://labs.idefense.com/
> 
> 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: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
> 



 




Copyright © Lexa Software, 1996-2009.