Hey folks,
Just wanted to cover an issue that is sure to come up regarding this release. For those that are watching this package, there is a possible security breach in libpgsql which this package interacts with.
According to http://cert.uni-stuttgart.de/advisories/apache_auth.php, there is a potential security flaw in libpgsql itself which could allow an attacker to add, drop, delete tables in a database.
A small excerpt from that page should suffice to explain the problem:
Vulnerability Type
SQL code insertion attack
Description
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, User);
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 beginning): '; 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.
This is an issue that I'll be taking up with the libpgsql upstream and debian package maintainer. The issue is whether to provide a transparent check+rewrite if this condition is found (with an appropriate log entry of course), block the execution completely with an error, or simply not check for this condition since this is an issue with libpgsql, not this package.
As soon as an appropriate course of action is defined, this package will be updated to reflect it.
David D.W. Downey
A.K.A "pgpkeys"