vulnerability. This fix completely removes the ability (hack) of being able
to bind a list of values in an in clause. It was demonstrated that by allowing
that functionality you open up the possibility for certain types of
sql injection attacks. The previous fix attempts all focused on preventing
the insertion of additional sql statements (the semi-colon problem:
xxx; any new sql statement here). But that still left the ability to
change the where clause on the current statement or perform a subselect
which can circumvent applicaiton security logic and/or allow you to call
any stored function.
Modified Files:
Tag: REL7_3_STABLE
jdbc/org/postgresql/Driver.java.in
jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
where the Object is a String and the type is numeric (i.e. INTEGER,LONG,etc).
The fix applies the standard escaping for these values.
Modified Files:
Tag: REL7_3_STABLE
jdbc/org/postgresql/Driver.java.in
jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
fixing an order by problem for index metadata results.
Also includes removing some unused code as well as a fix to the toString
method on statement.
Modified Files:
Tag: REL7_3_STABLE
jdbc/org/postgresql/jdbc1/AbstractJdbc1DatabaseMetaData.java
jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
following: select 1; commit; set autocommit true;
If this is submitted in one call to the server (the select 1 doesn't start a
new transaction like it should), however if the select 1 is sent as a separate
call then it works correctly.
Modified Files:
Tag: REL7_3_STABLE
jdbc/org/postgresql/jdbc1/AbstractJdbc1Connection.java
connection shutdown. This is a grotty workaround for a Tcl bug, but
said bug has been there long enough that I'm not holding my breath
for a real fix. Per discussions and testing from ljb and g.hintermayer.
fix uses explicit joins to avoid using the genetic query optimizer for
consistent results.
Modified Files:
Tag: REL7_3_STABLE
jdbc/org/postgresql/jdbc1/AbstractJdbc1DatabaseMetaData.java
believe I didn't notice this before -- once 64k was sent to/from the
server the client would crash. Basicly, in 7.3 the server SSL code set
the initial state to "about to renegotiate" without actually starting
the renegotiation. In addition, the server and client didn't properly
handle the SSL_ERROR_WANT_(READ|WRITE) error. This is fixed in the
second patch.
Nathan Mueller
first, that I missed when checking over 7.3.1, was that the client
method was switched to SSLv23 along with the server. The SSLv23 client
method does SSLv2 by default, but can also understand SSLv3. In our
situation the SSLv2 backwords compatibility is really only needed on the
server. This is the first patch.
The last thing is that I found a way for the server to understand SSLv2
HELLO messages (sent by pre-7.3 clients) but then get them to talk
SSLv3. This is the last one.
Nathan Mueller
"SSLv23_method(void), SSLv23_server_method(void), SSLv23_client_method(void)
A TLS/SSL connection established with these methods will understand the SSLv2,
SSLv3, and TLSv1 protocol. A client will send out SSLv2 client hello messages
and will indicate that it also understands SSLv3 and TLSv1. A server will
understand SSLv2, SSLv3, and TLSv1 client hello messages. This is the best
choice when compatibility is a concern."
This will maintain backwards compatibility for those us that don't use
TLS connections ...
