Slashdot Mirror
Serious Oracle Flaw Revealed; Patch Coming
GMGruman writes "A bug in Oracle Database that could take down large databases — or let a hacker do so — has been found, and Oracle promises a patch later today. When InfoWorld first heard of the bug two months ago, its investigation revealed how dangerous this bug could be, and after convincing Oracle to address the issue, InfoWorld held the news until a patch was available, so hackers could not exploit the bug in the meantime. Paul Venezia details just how this bug exposes companies to the possibility of databases going offline, and Eric Knorr asks Oracle users to help test the patch in their complex environments. (InfoWorld's tests in simpler environments show the patch works there.)"
...brought to you by InfoWorld! Submitted by InfoWorld! Seriously, how much is /. getting behind the scenes from the various IT rags that plaster the front page?
I'm sure "SlashdotMedia" will improve on all the wonders that Dice Holdings blessed us all with
I assume they're referring to:
http://www.oracle.com/technetwork/topics/security/cpujan2012-366304.html
My mystification is what is the venn diagram intersection of mysql server, virtualbox, and oracle 11G? Without any details I'm guessing a package signing key got owned?
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
The only reason Oracle has this flaw is because Microsoft's DB lineup hardly forces them to compete from a security perspective.
I wonder why nowadays they use an incrementing limited integer number (SCN), subject to the described bugs, instead of a worldwide consistent and unlimited number like the TIME. The synchronization of the databases respective times can always occur with the NTP service (http://en.wikipedia.org/wiki/Network_Time_Protocol).
Generally, a database flaw like this is of relatively minor concern for exactly that reason. In order for the flaw to be exploited, the attacker has to already have gotten past other layers of security. However, there is a pretty damaging aspect to this flaw: you don't need admin access to exploit it. Anyone with the ability to query the database can do damage. Obviously, anyone who gets that far is already in a position to do some serious damage even without this flaw, but it does add some insult to injury.
"You cannot simultaneously prevent and prepare for war." -- Albert Einstein
This isn't security through obscurity. This is an attempt to mitigate the damage while the flaw is being patched. Security through obscurity would be if they chose not to solve it, relying instead on nobody figuring it out.
"You cannot simultaneously prevent and prepare for war." -- Albert Einstein
The problem is that if you have your Oracle DB's linked together in the fashion described in the article, having just a single little random Oracle DB owned can result in a DOS of literally every Oracle DB in your company that is linked together. It's not limited to just the DB connected to the front end that was compromised.
Furthermore, from what I understood from the article, the only real way to recover from the DOS is to restore EVERY database from a backup after rolling back the SCN number on EVERY database you run. If you miss rolling back and updating just a single one, you're hosed again.
This is a really insidious bug.
No, the "ALTER DATABASE BEGIN BACKUP" was just how the issue was first discovered. The issue is that someone with *low* privileges on an obscure, minor DB server can bump the SCN on that server, which if it happens to be linked to any other servers (like your big important one), causes the SCN to get bumped on those servers. So you can DoS all the other servers.
We have been battling this since many a months now. Oracle's solution? set "_max_reasonable_scn_rate"=16384
No Sig for you.!
Information on the System Change Number (SCN) and how it is used in the Oracle Database [ID 1376995.1]
Modified 17-JAN-2012 Type BULLETIN Status PUBLISHED
Applies to:
Oracle Server - Enterprise Edition - Version: 10.1.0.5 to 11.2.0.3 - Release: 10.1 to 11.2
Information in this document applies to any platform.
Purpose
Read this article to get a high level overview of how a logical timestamp, called the System Change Number (SCN), is used to order database events, and how the advance of this logical timestamp is constrained.
Scope and Application
This document is intended for Oracle DBAs.
Information on the System Change Number (SCN) and how it is used in the Oracle Database
The system change number (SCN) is a logical, internal timestamp used by the Oracle Database. SCNs order events that occur within the database, which is necessary to satisfy the ACID properties of a transaction.
The database uses SCNs to query and track changes. For example, if a transaction updates a row, then the database records the SCN at which this update occurred. Other modifications in this transaction typically have the same SCN. When a transaction commits, the database records an SCN for this commit. Multiple transactions that commit at the same time may share the same SCN.
SCNs occur in a monotonically increasing sequence, and there is a very large upper limit to how many SCNs an Oracle Database can use - that limit is currently 281 trillion, or specifically 281,474,976,710,656 SCN values.
Given that there is an upper limit, it is important that any given Oracle Database does not run out of available SCNs. The Oracle Database uses a time based rationing system to ensure that this does not happen.
At any point in time, the Oracle Database calculates a "not to exceed" limit for the number of SCNs a database can have used, based on the number of seconds elapsed since 1988, multiplied by 16,384. This is known as the database's current maximum SCN limit. Doing this ensures that Oracle Databases will ration SCNs over time, allowing over 500 years of data processing for any Oracle Database.
The difference between the current SCN the database is using, and the "not to exceed" upper limit, is known as the SCN headroom. For almost all Oracle Databases, this headroom is constantly increasing every second.
However, Oracle has determined that some software bugs could cause the database to attempt to exceed the current maximum SCN value (or get closer to the limit than was warranted).
Generally if the database does try to exceed the current maximum SCN value, the transaction that caused this event would be cancelled by the database, and the application would see an error. The next second the limit increases, so typically the application then continues with a slight hiccough in processing. However, in some very rare cases, the database does need to shut down to preserve its integrity. In no cases is data lost or corrupted.
Similar to how clocks are kept synchronized in a computer network, when two databases communicate with each other over a database link, they synchronize their SCNs by picking the largest SCN in use by the two. So in some cases, databases experienced rapidly decreasing SCN headroom not because of a bug in that specific database, but because the bug was active in one or more of the databases that database was connected to. Since the database always rejects SCNs that exceed the current maximum SCN, the provision of being able to run Oracle Databases for more than 500 years was not affected in any of the cases.
All the associated bugs have been fixed in the January 2012 CPU (and associated PSU). The same fixes are also available in the database Patchset Update (PSU) and the latest Oracle Exadata and Windows bundled patches.
Some customers expressed concerns that they may be getting closer to the current maximum SCN limit faster than the data processing they are
Actually from the article, restoring a backup won't help. The SCN number is in there. They describe having to dump the Schema and Data to a newly created Oracle database. That would be a nightmare.
If they don't affix patches to the amputation areas the horns and tail keep growing back.