monline

A few days ago David Litchfield published a detailed analysis of the Oracle vulnerability he has found in February this year. The title says: "Lateral SQL Injection: A New Class of Vulnerability in Oracle". Finding the bug was a nice catch, but actually the feature leading to it is a pretty trivial source of problems, namely automatic datatype conversions.

I strongly discourage everyone from running Java in the JVM of Oracle 9i databases. I had two serious issues with it in a production environment (btw. fully patched to the latest patchset) and would never suggest to use Java in an Oracle PL/SQL session ever again.

To get to the point, here's an example for changing the HTTP port of XML DB's WebDav server:
Run it with user "SYS as SYSDBA" in the database.
Read on for some explanation of the details.

You can find a number of Oracle database vulnerabilities here, at the Red-Database-Security website. There're quite many, all of them at least one year old or even older. Using them takes not much knowledge and can easily compromise your database (application, server, ...).

Under some circumstances using a view that has an EXISTS() condition on a temporary table might cause an ORA-03113: end-of-file on communication channel error. This happens only if the view is merged by the query optimizer into the query. Using the NO_MERGE hint on the view fixes the issue. I experienced this on Oracle 9iR2 9.2.0.1.0 on a Win2003 server. The same query ran perfectly on a HP-UX box with 9.2.0.6.0 (using the same code and data). This is definitely a bug that was fixed somewhere between 9.2.0.1.0 and 9.2.0.6.0.

It has happened several times since I work with PL/SQL Developer that opening a table (I mean not the data rows of the table, but the table structure) for view or edit resulted in an ORA-01460 ("unimplemented or unreasonable conversion requested") error message. This used to happen only with unicode databases (UTF8 or AL32UTF8).

The documentation of Oracle 9iR2 says that the dbms_session.free_unused_user_memory() procedure can be used to free up memory that is not in use. They even have an example for index-by tables (in 9i they are called associative arrays) and it works just as expected. However the memory is only released if the table being used was indexed by a numeric datatype! For tables indexed by VARCHAR2 it will not free the memory. Try it yourself if you've doubts about it. Unfortunately I'm using VARCHAR-indexed PL/SQL tables quite heavily in my application (for caching table data) and this bug hit me pretty seriously. I've to rewrite a lot of code now so my app does not abort due to ORA-04030 (out of process memory) exceptions.

If you use the wpg_docload.download_file() procedure to download a BLOB to the browser, then be sure to close the BLOB prior the function call. Otherwise the browser will never get the contents of the BLOB (actually it'll never get an answer at all). I don't know whether this is a bug or not, but it occured to me on Oracle 9iR2 (Windows).

First you should read all the stuff in the standard Oracle docs. After that you can read these two pages with some less known details about temporary LOBs:

1. Chapter 17: Handling large objects (LOBs) - this is an addendum to the book "Practical Oracle 8i - Building Efficient Databases"
2. Temporary LOBs - this is a section of the "Oracle DBA Tips Corner" website