ðòïåëôù 


  áòèé÷ 


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: iDefense Security Advisory 01.09.06: Multiple Vendor mod_auth_pgsqlFormat String Vulnerability



> 
> Multiple Vendor mod_auth_pgsql Format String Vulnerability
> 
> iDefense Security Advisory 01.09.06
> http://www.idefense.com/intelligence/vulnerabilities/display.p
> hp?id=367
> January 09, 2006
> 
> I. BACKGROUND
> 
> The mod_auth_pgsql apache module allows user authentication against
> information stored in a PostgreSQL database. More information can be
> found at the following site:
> 
>     http://www.giuseppetanzilli.it/mod_auth_pgsql2/
> 
> II. DESCRIPTION
> 
> Remote exploitation of a format string vulnerability in multiple
> versions of the mod_auth_pgsql authentication module for the Apache
> httpd could allow the execution of arbitrary code in the 
> context of the
> httpd.
> 
> The mod_auth_pgsql module for the Apache httpd is a third party
> authentication module which allows authentication details to be stored
> in a PostgreSQL database. Although this is a third party module, it is
> available as a package for several distributions, including Red Hat
> Linux, Debian GNU/Linux and FreeBSD.
> 
> Due to a design error, many of the logging functions in this 
> module take
> user supplied values as input to the format specifier. An example of
> this is shown below:
> 
>     ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, pg_errstr);
> 
> When part of the error message contains a format string 
> specifier it is
> processed. For example, for the username "%x%x%x%x%x", output  similar
> to the following may appear in the 'error_log' file for the  targetted
> httpd:
> 
> [Tue Sep 23 11:34:38 2005] [error] [client 10.1.10.11] mod_auth_pgsql:
>  Password for user 406869a083b3c900083b3cb3 not found 
> (PG-Authoritative)
> 
> The sequence of hex characters is the result of the ap_log_rerror()
> function parsing the input string as a format string, and contains
> values from the stack. When the name supplied causes an invalid memory
> access, the child process may exit with a logged error similar to:
> 
> [Tue Sep 24 11:25:53 2005] [notice] child pid 12345 exit signal
>  Segmentation fault (11)
> 
> III. ANALYSIS
> 
> Successful exploitation allows remote attackers to gain local 
> access to
> the vulnerable system in the context of the affected httpd. 
> In order to
> exploit this vulnerability, the attacker must know the URI of at least
> one reource on the web server which is configured to use this 
> module for
> authentication. This module is not installed by default, but is
> available as a package from some vendors, including Red Hat. 
> Additional
> configuration is required before the module is active after 
> installing.
> 
> While format string exploit techniques are well documented, most
> discussions of and exploits for vulnerabilities containing 
> them rely on
> the user supplied string being located on the stack. The reason for
> this is that it allows the attacker to directly supply pointers to the
> memory locations they wish to modify via the %n format specifier. As
> this module does not store the format string on the stack, 
> this may make
> exploitation more difficult as techniques for exploiting this kind of
> format string are not as commonly known. However, such information is
> publicly available.
> 
> Successful exploitation would allow a remote unauthenticated 
> user access
> to an affected system with the permissions of the httpd itself.
> 
> IV. DETECTION
> 
> iDefense has confirmed the existence of this vulnerability in version
> 2.0.2b1 of mod_auth_pgsql for Apache 2.x. It is suspected that earlier
> versions are also affected.
> 
> V. WORKAROUND
> 
> Disable the module, and use another form of authentication for the
> affected resource.
> 
> In order to disable the module on Red Hat systems, execute 
> the following
> commands as root:
> 
>   cd /etc/httpd/conf.d
>   mv auth_pgsql.conf auth_pgsql.disabled
> 
> If you have any '.htaccess' files, you may also have to disable any
> authentication with references to mod_auth_pgsql directives. These
> directives all start with 'Auth_PG_'.
> 
> At this point, you should add another authentication method for the
> resources that were protected by this module. The exact operations to
> perform are dependant on which authentication method you 
> choose to use.
> 
> After performing these steps, restart the httpd by executing the
> following command as root:
> 
>   /sbin/service httpd restart
> 
> For other distributions, the general steps are the same (disable the
> module, add another form of authentication, and restart the httpd),
> however the details may vary slightly.
> 
> VI. VENDOR RESPONSE
> 
> The maintainer has released mod_auth_pgsql 2.0.3 to address this
> vulnerability, which is available for download at:
> 
>   http://www.giuseppetanzilli.it/mod_auth_pgsql2/dist/
>  
> Red Hat, Inc:
> 
> Updates are available for Red Hat Enterprise Linux 3 and 4 to correct
> this issue.  Red Hat Enterprise Linux 2.1 was not affected by this
> issue. New mod_auth_pgsql packages along with our advisory 
> are available
> at the URL below and by using the Red Hat Network 'up2date' tool.
>  
>  https://rhn.redhat.com/errata/RHSA-2006-0164.html
> 
> Updates are available for Fedora Core 3 and 4 to correct this issue.
>  
>  
> www.redhat.com/archives/fedora-announce-list/2006-January/msg0
> 0016.html
>  
> www.redhat.com/archives/fedora-announce-list/2006-January/msg0
> 0015.html
> 
> VII. CVE INFORMATION
> 
> The Common Vulnerabilities and Exposures (CVE) project has 
> assigned the
> name CVE-2005-3656 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
> 
> 11/15/2005  Initial vendor notification
> 11/22/2005  Initial vendor response
> 01/09/2006  Coordinated public disclosure
> 
> IX. CREDIT
> 
> The discovery of this vulnerability is credited to Sparfell.
> 
> Get paid for vulnerability research
> http://www.idefense.com/poi/teams/vcp.jsp
> 
> Free tools, research and upcoming events
> http://labs.idefense.com
> 
> X. LEGAL NOTICES
> 
> Copyright (c) 2006 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
> email 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.
> _______________________________________________
> To unsubscribe, go here:
> http://www.idefense.com/mailman/listinfo/idlabs-advisories
> 




 




Copyright © Lexa Software, 1996-2009.