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.)"

Nice Slashvertisement

[Megaweapon]

...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?

Original source

[vlm]

I assume they're referring to:

http://www.oracle.com/technetwork/topics/security/cpujan2012-366304.html [oracle.com]

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?

Re:Original source

[gringer]

Reading that article kept bringing forward more "oh no" realisations, stemming from the following points:

1. like time, the SCN cannot decrement. It must always tick forward
2. when Oracle databases link to each other, maintaining data consistency requires them to synchronize to a common SCN. This is necessarily the highest SCN carried by any participating Oracle database
3. If the soft limit [16384 times the number of seconds since 00:00:00 01/01/1988] is exceeded, the database can become unstable and/or unavailable.

The "recovery" for exceeding the soft limit is to shut down the databases until the SCN goes below the soft limit. From then on, you just have to hope that no databases you're synchronising with will have a SCN that is close to (or beyond) this soft limit.

Re:You expose your DB server?

[Rary]

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.

Re:You expose your DB server?

[Hulfs]

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.