Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
From: Chris Wysopal (weldvulnwatch.org)
Date: Wed Aug 29 2001 - 16:52:13 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    Vulnerabilities in several Apache authentication modules

       RUS-CERT has discovered that several Apache authentication modules
       which use SQL databases to store authentication information are
       vulnerable to a remote SQL code injection attack.

      Systems Affected

       Any Apache server using database-based authentication with the
       following modules:

         * AuthPG 1.2b2 by Min S. Kim (also known as mod_auth_pg)
         * mod_auth_mysql 1.9 by Vivek Khera
         * mod_auth_oracle 0.5.1 by Serg Oskin
         * mod_auth_pgsql 0.9.5 by Guiseppe Tanzilli and Matthias Eckermann
         * mod_auth_pgsql_sys 0.9.4 (by the same authors, modifications by
           Victor Glushchenko)

       It is possible that other authentication modules not listed above are

      Systems Not Affected

       RUS-CERT has examined the following authentication modules and
       verified that an Apache server using these modules is not vulnerable
       to the problem described in this document:

         * mod_auth_mysql 2.20 by Zeev Suraski
         * mod_auth_ora7 1.0 by Ben Reser
         * mod_auth_ora8 1.0 by Ben Reser

      Attack vector

       HTTP requests sent to the Apache server using the vulnerable
       authentication modules.


       In the case of the PostgreSQL modules, an attack can execute arbitrary
       SQL statements or cause the database query for the password to return
       arbitrary data. As a result, unauthorized access to the web server is

       With the Oracle module, the attacker can call stored procedures and
       cause the database query for the password to return arbitrary data.
       The impact with MySQL is currently unclear, but with the advent of
       stored procedures, harmful side effects might become possible as well.

      Vulnerability Type

       SQL code insertion attack


       During the authentication process, the password hash has to be looked
       up in the database, so a SQL SELECT statement has to be built. In the
       vulnerable modules, this is done using code equivalent to the
       following pseudocode:

    Query := Sprintf ("SELECT %s FROM %s WHERE %s = '%s'",
                      Password_Column, User_Table, User_Column,

       Later on, the retrieved password hash is compared with the one
       supplied by the user trying to authenticate.

       However, the value of User has been received over the network. Suppose
       an attacker choses the string (note the single quotation mark at the

    '; SELECT 'wA8aGH92dPQnIDD

       Now the resulting string contains two SQL statements:

         SELECT password_column FROM user_table WHERE user_column = '';
         SELECT 'wA8aGH92dPQnIDD'

       PostgreSQL's libpq client library will transmit both statements to the
       PostgreSQL server. The server will execute both statements and return
       the result of the second to the client. This way, an attacker can make
       it appear to the authentication code that the database contains the
       proper hash for the password it just has provided. Other forms of
       attacks are possible by issuing INSERT or DELETE statements in
       essentially the same manner, of course.

       In the MySQL and Oracle cases, the impact of the vulnerability is
       different. Oracle does not seem to allow multiple SQL statements per
       query, but using a UNION clause to add additional data seems to be
       possible, so the attack given above can be duplicated. In addition,
       stored procedures can be called, with a potential for harmful side
       effects. We were unable to obtain a definite answer if the
       vulnerability is exploitable if a MySQL database is used, since MySQL
       neither supports UNION clauses nor stored procedures.

      Proposed Solution


       We believe that the fact that the essentially the same vulnerability
       is present in many PostgreSQL applications is related to the lack of a
       suitable string quoting function in the PostgreSQL client library (and
       not just to code reuse and overlap among the authors).

       Therefore, we propose that a function which escapes characters treated
       specially by the PostgreSQL by replacing them with safe character
       sequences is included in the PostgreSQL client library. We provide a
       mostly untested sample implementation:

         * Escaping Strings in PostgreSQL Queries

       Some of the fixed versions below already implement this suggestion.

        MySQL and Oracle

       Both the MySQL and Oracle client libraries provide a suitable function
       for quoting strings in SQL queries. The authentication modules which
       are not vulnerable (see above) use them, so we propose to use these
       modules, or the fixed versions below.

      Patched Versions

       Several authors have already reacted and released new versions:

         * AuthPG 1.3 by Min S. Kim (http://authpg.sourceforge.net/)
         * mod_auth_mysql 1.10 by Vivek Khera (ftp://ftp.kcilink.com/pub/)
         * mod_auth_pgsql 0.9.6 by Guiseppe Tanzilli

       Serg Oskin has announced a fixed version as well.

      Contact Status

       RUS-CERT contacted the authors of the vulnerable authentication
       modules on 2001-08-23.

      About RUS-CERT

       RUS-CERT (http://cert.uni-stuttgart.de/) is the Computer Emergency
       Response Team located at the Computing Center (RUS) of the
       University of Stuttgart, Germany.

      URI For This Advisory


    Florian Weimer 	                  Florian.WeimerRUS.Uni-Stuttgart.DE
    University of Stuttgart           http://cert.uni-stuttgart.de/
    RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898