Red Hat Bugzilla – Bug 807394
CVE-2012-1618 postgresql-jdbc: SQL injection due improper escaping of JDBC statement parameters
Last modified: 2013-04-30 10:10:28 EDT
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.
This issue affects the version of the postgresql-jdbc package, as shipped with Red Hat Enterprise Linux 5.
This issue did NOT affect the version of postgresql-jdbc package, as shipped with Red Hat Enterprise Linux 6.
This issue did NOT affect the versions of the postgresql-jdbc package, as
shipped with Fedora release of 15 and 16.
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. The Red Hat Security Response Team agrees with their assessment and so does not consider this to be a security flaw.
(In reply to comment #11)
> Further links:
>  http://archives.postgresql.org/pgsql-committers/2010-07/msg00210.php
The server-side release note warning foreseen there is the first compatibility item in the 9.1 release notes:
Assigned CVE as per http://www.openwall.com/lists/oss-security/2012/04/04/9
First off: I agree this is not an issue in PostgreSQL upstream. This
issue only occurs with an ancient unsupported and obsolete version of
the JDBC driver when being used with a newer version of PostgreSQL.
However having stated that there is a security boundary violation
going on. Just because a software component is out of date or not
supported doesn't mean security bugs shouldn't at least be
acknowledged (software tends to live past its designed lifetime). Add
to this the fact that someone actually reported it we can state with
some certainty that it affected at least one person, ergo there is a
reasonable chance it may affect others.
So I checked the CVE database, we have 64 instances of "when used
with", some reasonable examples:
CVE-2009-4040,Candidate,"Cross-site scripting (XSS) vulnerability in
phpMyFAQ before 2.0.17 and 2.5.x before 2.5.2, when used with Internet
Explorer 6 or 7, allows remote attackers to inject arbitrary web
script or HTML via unspecified parameters to the search
CVE-2008-2705,Candidate,"Unspecified vulnerability in Sun Java System
Access Manager (AM) 7.1, when used with certain versions and
configurations of Sun Directory Server Enterprise Edition (DSEE),
allows remote attackers to bypass authentication via unspecified
So I think it's safe to say that we can (and should) assign CVE's
based on the unintended interactions of products (assigning a CVE
helps ensure that people are more likely to find out, security
scanners all love to pick up on CVE's, etc.). I'm going to assign a
CVE for this and suggest a description of (stolen directly from the
first bug report
"When using PostgreSQL JDBC driver version 8.1 to connect to a
PostgreSQL version 9.1 database, escaping of JDBC statement parameters
does not work and SQL injection attacks are possible. It should be
noted that the PostgreSQL JDBC driver version 8.1 is officially
obsolete and should not be used."
Please use CVE-2012-1618 for this issue.