Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 30 Mar 2012 14:28:02 +0200
From: Jan Lieskovsky <>
To: "Steven M. Christey" <>
CC:, Tom Lane <>,, Steffen Dettmer <>
Subject: CVE DISPUTE notification: postgresql-jdbc: SQL injection due improper
 escaping of JDBC statement parameters

Hello Kurt, Steve, vendors,

   originally, the following deficiency has been reported by Steffen Dettmer:

A SQL injection flaw was found in the way postgresql-jdbc, a JDBC driver for
PostgreSQL database, performed escaping of certain JDBC statement parameters. A
remote attacker could provide a JDBC statement with specially-crafted
parameters, which once processed by the postgresql-jdbc driver would lead to
SQL injection.


Upon further issue investigation and discussion with Tom Lane of PostgreSQL
upstream and JDBC driver upstream the following conclusion has been provided:

The upstream development team of the JDBC driver for the PostgreSQL database
does not consider improper escaping of certain JDBC statement / query
parameters, when the JDBC driver of version older than the version of
underlying PostgresSQL server is being used, to be a security defect. In
general, the JDBC driver for the PostgreSQL database does not promise to work
with server releases newer than the driver release.

This is NOT an official JDBC driver for PostgreSQL database development team
statement yet (in the sense it would reference some upstream document / web page).
Anyway, we have got preliminary notification there is a upstream intention to
provide such page (document which postgresql-jdbc versions are expected to work
correctly with which versions of PostgreSQL database server).

Till this is done, please take this post as a clarification of postgresql-jdbc's
upstream intentions to dispute the possibly later allocated CVE identifier to this
issue (posting this sooner yet one can be allocated to this though some vendors
might still be interested in allocation).

For now Red Hat Security Response Team decided to agree with the above upstream
assessment / pursue the way to upstream conclusion. Though in the future if some
further details would appear, forcing us to change this conclusion, we might
revisit our decision.

Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Response Team

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.