How and where to report a vulnerability? [message #255314] |
Tue, 31 July 2007 06:26 |
zenyatta
Messages: 2 Registered: July 2007
|
Junior Member |
|
|
Hi all,
I have discovered a bug in the JDBC driver. I know it's near impossible to bring a bug to Oracle's attention unless you're a paying customer. I don't actually care for having it fixed as it's easy to work around - but I spent quite a few hours investigating it and my results could save someone else time & effort should they encounter the same symptoms.
I thought about posting a test case in a forum such as this but I'm reluctant. The bug could be used - in theory - to craft a minor denial of service attack. The only scenario I could think of is low-impact and low-probability but I don't know enough about Oracle to properly judge if publishing this would be reckless or not.
Can anyone suggest the responsible course of action? Any advice is appreciated...
|
|
|
|
Re: How and where to report a vulnerability? [message #255331 is a reply to message #255314] |
Tue, 31 July 2007 08:13 |
zenyatta
Messages: 2 Registered: July 2007
|
Junior Member |
|
|
Thanks for the response,
so: I connect to Oracle 10.2.0.1.0 using ojdbc14.jar, version 10.2.0.2.0, thin driver. An account must be on the server that's able to connect via JDBC and has a select privilege on a table.
Then, if the database is in a certain state, I can cause certain PreparedStatements of the form
select * from (...) where ROWNUM <= ?
to return incorrect results. More specifically, instead of
min(actualResults, maxResults)
the number of returned records is
min(actualResults, maxResults, fetchSize)
where
actualResults = the number of records returned by the nested query
maxResults = the value set in the PreparedStatement
fetchSize = the fetch size valid during the current execution of the PreparedStatement (this is set by default (10) or explicitly via Statement.setFetchSize())
I found two ways to reverse this condition: 1) shutdown & re-start Oracle or 2) drop & re-create at least one of the tables touched by the misbehaving PreparedStatement. It would seem, therefore, that the bug disrupts the compilation of the statement's execution plan which is then broken until evicted from wherever it lives.
The described type of query is common in web UIs with paginated lists; this bug can cause only parts of the requested data to be displayed, which can be a minor nuisance or a serious disruption depending on context. With a badly-validating Java webapp, a remote attacker could conceivably trigger this behavior using nothing but HTTP (but that's obviously out of scope of ojdbc). The exact trigger conditions are quite unlikely to occur in the wild, however, so it is probably a non-issue...
z.
[Updated on: Tue, 31 July 2007 08:21] Report message to a moderator
|
|
|