Обсуждение: 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:
   [1] http://seclists.org/bugtraq/2012/Mar/125

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.

References:
[2] http://lists.opensuse.org/opensuse-security/2012-03/msg00024.html
[3] https://bugzilla.novell.com/show_bug.cgi?id=754273
[4] https://bugzilla.redhat.com/show_bug.cgi?id=807394

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

What follows is just one perspective from a DBA at a production
shop.

Jan Lieskovsky <jlieskov@redhat.com> wrote:

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

Presumably you are aware of this section on the download page:

http://jdbc.postgresql.org/download.html#current

Which says:

| This is the current version of the driver. Unless you have unusual
| requirements (running old applications or JVMs), this is the
| driver you should be using. It supports Postgresql 7.2 or newer
| and requires a 1.4 or newer JVM. It contains support for SSL and
| the javax.sql package. It comes in two flavors, JDBC3 and JDBC4.
| If you are using the 1.6 or 1.7 JVM, then you should use the JDBC4
| version.
|
| JDBC3 Postgresql Driver, Version 9.1-901
|
| JDBC4 Postgresql Driver, Version 9.1-901

And the section on supported versions of PostgreSQL:

http://www.postgresql.org/support/versioning/

... which shows version 8.1 as having reached end-of-life and gone
out of support five years after release, in November, 2010.  As far
as I could tell from a quick skim of the referenced links, this
problem only exists when using this out-of-support version of the
JDBC driver.

While I certainly can't speak for the PostgreSQL community, I can
say that the shop at which I work (the Consolidated Courts
Automation Program of the Wisconsin Supreme Court), we pay attention
to these pages and never consider it safe to use an unsupported
version.  We upgrade our JDBC drivers as soon as practicable
whenever the recommended version on the JDBC download page changes.
Of course, this is assigned to be done with some application
software release and the JDBC version rolls out through development,
testing, and staging servers before it is deployed to production, as
we do with the server product itself.

It is frequently mentioned on the PostgreSQL support lists that it
is not a good idea to use older drivers and client libraries with
newer servers, although the opposite is supported.  We respect this
advice, and it seems reasonable to us.  If that's not mentioned
explicitly on an official web page, I agree that it should be.

-Kevin

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/30/2012 06:28 AM, Jan Lieskovsky wrote:
> Hello Kurt, Steve, vendors,
>
> originally, the following deficiency has been reported by Steffen
> Dettmer: [1] http://seclists.org/bugtraq/2012/Mar/125
>
> 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.
>
> References: [2]
> http://lists.opensuse.org/opensuse-security/2012-03/msg00024.html
> [3] https://bugzilla.novell.com/show_bug.cgi?id=754273 [4]
> https://bugzilla.redhat.com/show_bug.cgi?id=807394
>
> 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.

Apologies for the delay, at first I agreed with the above, but then I
checked and I think it's a bit more nuanced than that.

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
page.","CONFIRM:http://www.phpmyfaq.de/advisory_2009-09-01.php

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
vectors.","SUNALERT:238416

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
(http://lists.opensuse.org/opensuse-security/2012-03/msg00024.html):

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


- --
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPfKHoAAoJEBYNRVNeJnmT/u4QAI03PTYXs1ceSoMIZ1ORjj7x
vFTKfdOaXercFFonIrVzf4e54gCObUJgse3rdz6ONh59FkqDSDW1WISYhLi+pMAj
fLCng+vaB3ctiI6KurenKpy1fIWg9CsNTsx+9N2UG0JorMYp9hhih/9KRcwcvbLV
TXl7psu7OhOKc6J2re1bjQO+gbyVPZxvkYfs1CvXvIh27FWWzoNFYLL34rRdZIwo
fcfy5z7AWEehxpPRRBijllYVQambqdXu2m8PBRLn7pgy/dRPuDbn/yiKcC39+1EK
jcaiFH7P1XtXXQouy13Ta3yhHsZiVDZmNyR+YKnRYQIY9ICjFNxR+rdBbSM0f2Eu
JO1Sa9eewe7bsylIchIRoVtGuzvOlxv18Dujp6iD7pvIaLNJ9uuuabz9lX/9rm3p
WX++VxYk+k+cGOGjttnlSfiS+TYnFjLgS6fM4AAp6oBPg13ndrKJL4m7qYNoJzjd
S4JhOxn8VcgRFAo8otLzIRxWrsYYG8/xybr5/NESmC8hcr0mhYUIGyLx5qu0/QAR
ri1QT3BPs7SoqGGaJHUZtqOK/vAkDHn1SdA/VopWcpk2XmP2rd0h0Mh+jkA3Pd6C
SaL2HvwRq9a9T9rJozESHnPd8HqvDgaUdKADcYEV9xS+axZMHRPpHSppvt93GKao
ClES06wUx2zOrWyNijbF
=jlUp
-----END PGP SIGNATURE-----

Kurt Seifried <kseifried@redhat.com> writes:
> 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
> (http://lists.opensuse.org/opensuse-security/2012-03/msg00024.html):

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

Well, if you want to have a CVE for this, you should use a more
complete description.  The actual scenario is that pre-8.2 versions
of the JDBC driver do not know about the "standard_conforming_strings"
option of more recent Postgres servers, and are insecure with *any*
Postgres server in which that option is turned on, which has been
possible since server version 8.2.  What changed in the 9.1 server
is that that option is now on by default.  It's still possible
(and will remain so for the foreseeable future) to turn the option off
in the server configuration, making this and other ancient clients
secure again.  But that isn't the default anymore.

            regards, tom lane

On 04/04/2012 01:47 PM, Tom Lane wrote:
> Kurt Seifried <kseifried@redhat.com> writes:
>> 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
>> (http://lists.opensuse.org/opensuse-security/2012-03/msg00024.html):
>
>> "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.
>
> Well, if you want to have a CVE for this, you should use a more
> complete description.  The actual scenario is that pre-8.2 versions
> of the JDBC driver do not know about the "standard_conforming_strings"
> option of more recent Postgres servers, and are insecure with *any*
> Postgres server in which that option is turned on, which has been
> possible since server version 8.2.  What changed in the 9.1 server
> is that that option is now on by default.  It's still possible
> (and will remain so for the foreseeable future) to turn the option off
> in the server configuration, making this and other ancient clients
> secure again.  But that isn't the default anymore.
>
>             regards, tom lane

Ahh perfect, thanks for the extra details!

--
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993