InfoWorld magazine published an detailed article regarding Oracle Database security flaw yesterday. InfoWorld says Oracle requested them to hold the story until they release a patch for the flaw. The flaw is related with System Change Number (SCN). If SCN is increased beyond the current maximum value (SCN Headroom or Maximum Reasonable SCN), database gives ORA-600 errors and crashes.

As we know, the System Change Number (SCN) is a number that increments sequentially with every database commit (inserts, updates, and deletes), and usually it’s not possible to reach the maximum value. The biggest problem is the SCN is also incremented through linked database interactions.

As I see, most Oracle experts do not realize the importance of this security threat. Some people even say that the Oracle SCN issue is a storm in a teacup. I think they miss that it’s possible to increase the SCN intentionally and use database links to exploit the bug. So let’s create a storm in a teacup 🙂 I should remind you that I will not take any responsibility if you mess up your databases. Just read the blog, do not test it on your systems.

I’ll setup a simple scenario to demonstrate the danger. I’ll create an ordinary user which has only a table on a VICTIM server. Here’s the SQL script:

Just a simple account which will access to his own table. I haven’t tested but I think it’s even possible to use an account with only-read access.

The attacker needs a dummy database (even installed on his own pc). So I’ve installed a dummy database to my own PC. Both my victim and dummy databases are Oracle 9i. After installation, I started the dummy DB in mount mode and dumped the control file:

It’s easy to read the SCN number (trace file is located in udump directory):

10817 in hexadecimal is equal to 67607 in decimal. I shut down my dummy DB, opened the control file in a hex editor, searched for the first occurrence of the hexadecimal array (“15 08 01”). This is the current SCN of the database. Oracle uses a 16-bit checksum algorithm for the control file (at least for Oracle 9i), so I modified two “words” (4 bytes) instead of one word (2 bytes).

Original bytes (in control file):

17 08 – 01 00 – 00 00 – 00 00

Modified bytes:

17 08 – 01 00 – 80 0B – 80 0B

As I said last 2 bytes (1 word) will not be used for SCN, I use it to pass the checksum. So new SCN will be about 12644383787031!!! I copied the modified control file over the original ones, started my dummy database and then checked the SCN:

The scnhealthcheck.sql script is distributed in the official patch to evaluate the risk of your database! It simply calculates the max SCN and headroom. C is the dangerous rate.

Here’s the output of same SQL on my victim DB:

I’ve created a database link to victim database and issued a select query on my dummy database:

Then I re-run the control.sql file in VICTIM database:

As you see, it is a very serious flaw so all DBAs should apply the CPU as soon as possible.