>
> 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
>