Oracle SCN Vulnerability

Over the past two months, InfoWorld has been researching a flaw in Oracle’s flagship database software that could have serious repercussions for their customers, potentially compromising the security and stability of Oracle database systems.  There is a very detailed article at the link provided above, and a follow-up from InfoWorld here.  The “boiled down” version:

The flaw could make any unpatched Oracle Database vulnerable to attack, and could pose a special risk to large Oracle customers with interconnected databases.  Both vulnerabiilties stem from a mechanism that most Oracle DBAs seldom deal with.  At the core of this issue is the System Change Number (SCN) in Oracle.  This is a number that increments sequentially with every database commit and is crucial to normal Oracle database operation.  The SCN is also incremented through linked database activities.

The SCN “time stamp” is the key to maintaining data consistency in Oracle, allowing the database to respond to every query with the appropriate version of data at a given point in time.  It works like a clock for database transactions, and like time, cannot move backwards.

When Oracle databases link to each other, they synchronize to a common SCN to maintain data consistency.  This is the highest SCN carried by any participating Oracle database instance because the SCN clock runs forwards only.  Only very basic permissions are required to make a connection that can cause one database to increment the SCN on another.

Oracle’s architects knew the SCN needed to be a massive integer.  It is a 48-bit number (281,474,976,710,656).  It would take eons for an Oracle database to eclipse that number of transactions and cause problems, or so you might think…

There is also a “soft-SCN” threshold, intended to alert when the SCN is getting close to its limit, or jumping to a much higher number.  Issuing the ‘BEGIN BACKUP’ command causes the SCN for a database instance to increase dramatically, so that the SCN continues to increase at an accelerated rate even after the ‘END BACKUP’ command is given.  Performing a hot backup can increase the SCN value by millions or billions, and that elevated growth continues as the process runs.  In most cases the SCN limits are so far out of reach that the occasional jump in number isn’t a cause for concern, and go unnoticed.  Some large Oracle customers have hundreds of database servers running hundreds of Oracle instances interlinked throughout the infrastructure.  When you mix the hot backup bug with large numbers of interconnected databases, the combination can result in widespread SCN elevation.

Oracle released a patch to fix the SCN growth rate bug in hot backup listed as 12371955: “High SCN growth rate from ALTER DATABASE BEGIN BACKUP in 11g.” If you have not already done so, Oracle recommends that you install this patch immediately.