Re: [oss-security] CVE DISPUTE notification: postgresql-jdbc: SQL injection due improper escaping of JDBC statement parameters
От | Kurt Seifried |
---|---|
Тема | Re: [oss-security] CVE DISPUTE notification: postgresql-jdbc: SQL injection due improper escaping of JDBC statement parameters |
Дата | |
Msg-id | 4F7CA5C6.3010207@redhat.com обсуждение исходный текст |
Ответ на | Re: [oss-security] CVE DISPUTE notification: postgresql-jdbc: SQL injection due improper escaping of JDBC statement parameters (Tom Lane <tgl@redhat.com>) |
Список | pgsql-jdbc |
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
В списке pgsql-jdbc по дате отправления: