Serious Oracle Flaw Revealed; Patch Coming

Nice Slashvertisement by Megaweapon · 2012-01-17 05:00 · Score: 2, Interesting

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

Re:Nice Slashvertisement by Ihmhi · 2012-01-17 05:09 · Score: 1, Funny

Seriously, how much is /. getting behind the scenes from the various IT rags that plaster the front page?
At least enough money that it's worthwhile to keep doing it?

--
Random Thoughts From A Diseased Mind (Not For Dummies)
Re:Nice Slashvertisement by HBI · 2012-01-17 05:21 · Score: 2

Until people stop reading. I stopped reading the trade rags a decade ago because of all the sponsored content and the fact that they gave zero insight. If /. is just trade rag bullshit, then why even come here?

--
HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.
Re:Nice Slashvertisement by Grave · 2012-01-17 05:23 · Score: 5, Insightful

Given that it's a fairly decent article about a somewhat (or very, for large companies) significant bug in a widely-used database, I think it still qualifies as "News for Nerds", doesn't it?
Re:Nice Slashvertisement by kiwimate · 2012-01-17 05:41 · Score: 2

It's not, at least not yet. I think a bigger problem is you have so many people posturing and proclaiming and acting as experts and simply flat-out speculating (incorrectly and/or uselessly), that the noise to signal ratio makes it less and less useful to read unless I want to spend ages digging through the cruft to figure out what's actually insightful or informative. In too many cases, merely targeting the +4 or +5 moderated posts doesn't guarantee that you're going to read something that is, you know, actually accurate.
Combined with the rampant stories on heavily political issues (copyright infringement comes to mind) where any shred of actual debate gets drowned out by all the "me too" posts, and Slashdot quite often just gets passed over by me. I don't have time.
And yet, I'm still posting here. As are plenty of people with similar (or differing) complaints. That's success for you.
Re:Nice Slashvertisement by Anonymous Coward · 2012-01-17 05:41 · Score: 4, Funny

If /. is just trade rag bullshit, then why even come here?
First posts and goatse.
Re:Nice Slashvertisement by Megaweapon · 2012-01-17 05:54 · Score: 2

Not by much, "Corporate Expensiveware Has Bug, Film At 11" isn't interesting nor very "nerdy" on its own. If you watch what gets frontpaged and who the submitters are lately, it should become obvious that modern /. is just clickbait for the big IT rags. I doubt this is merely coincidence, so I'm wondering what's going on behind the scenes.

--
I'm sure "SlashdotMedia" will improve on all the wonders that Dice Holdings blessed us all with
Re:Nice Slashvertisement by thetoadwarrior · 2012-01-17 06:26 · Score: 1

Someone's got sand up their ass.
Re:Nice Slashvertisement by nigelo · 2012-01-17 06:28 · Score: 2

Yes, but it's terribly nerdy to blithely dismiss these stories if you don't use/like/know-anything-about the software, isn't it?
Thus, still really suitable for posting to this site.

--
*Still* negative function...
Re:Nice Slashvertisement by pak9rabid · 2012-01-17 06:31 · Score: 2

Slashdot: Come for the first post, stay for the goatse

That has a nice ring to it.
Re:Nice Slashvertisement by Megaweapon · 2012-01-17 06:40 · Score: 1

Yes, but it's terribly nerdy to blithely dismiss these stories if you don't use/like/know-anything-about the software, isn't it?
Yeah, I work in an Oracle shop. I've also been on /. since it was on Malda's Alpha. My point is the intent of the submission, since there's plenty of nerdy stuff to post besides some piece about turtleneckboy's latest crapware bug written up on just another industry rag.

--
I'm sure "SlashdotMedia" will improve on all the wonders that Dice Holdings blessed us all with
Re:Nice Slashvertisement by sjames · 2012-01-17 06:41 · Score: 1

Yet I would rate TFA as interesting and good to know.
Re:Nice Slashvertisement by sjames · 2012-01-17 06:45 · Score: 1

The way the failure can hop from DB to DB as they connect was interesting. It's a bug that causes failures that propagate virus like.
Re:Nice Slashvertisement by jc42 · 2012-01-17 06:53 · Score: 2

If /. is just trade rag bullshit, then why even come here?
Because it's all put into perspective by people like you.

--
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Re:Nice Slashvertisement by afabbro · 2012-01-17 08:36 · Score: 1

Not by much, "Corporate Expensiveware Has Bug, Film At 11" isn't interesting nor very "nerdy" on its own.
In this case, there was a very detailed and interesting explanation of why and how the bug is caused, and it doesn't require you to know anything about Oracle to appreciate the engineering choice made and why the bug hits it.

--
Advice: on VPS providers
Re:Nice Slashvertisement by Anonymous Coward · 2012-01-17 09:26 · Score: 0

I'm here for the hot grits.
Re:Nice Slashvertisement by rnturn · 2012-01-17 16:32 · Score: 1

I'd disagree but I guess we'll find out how irrelevant this news is when we find that our credit cards aren't being accepted because the processor has had to shut their database again while they patch another Oracle database. I use /. as a one-stop shopping for much of my tech news. I don't find the occasional article about non-Linux software to be be a problem. I know I learned something new today. While I previously knew about the SCN, I didn't know it was a built-in timebomb. Oracle did a couple of things that we've all come to consider pretty stupid: hard-coded limits like the 48-bit size for the SCN, and the 16K value described in the article probably seemed like infinite in size back in 1988. Just like programs that could only handle 9999 records before blowing up, 2-digit year fields, etc. I probably wouldn't have learned about this flaw until much later if /. hadn't reported on the IW article. I gave up on IW ages ago. I'm glad someone's reading their site so I don't have to.
After reading this article, I'm thinking that Oracle is going to be the most hated company on the planet if they arbitrarily cut off the patch for older databases. Some applications (I'm thinking healthcare-related, anything covered by FDA regulations, etc.) can't upgrade just because a new version of software has come out. I expect there'll be quite a bit of pressure to make the patches available for all versions of their database that you can get support for.

--
CUR ALLOC 20195.....5804M
Re:Nice Slashvertisement by Saija · 2012-01-18 06:24 · Score: 1

Nice ring and goatse in the same reply?
I can't wash that mental image away from my mind...

--
Slashdot ya no es que lo era! ;)

They're "patching" Larry Ellison? by Kenja · 2012-01-17 05:11 · Score: 1

That sounds kind of ominous.

--

"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"

Re:They're "patching" Larry Ellison? by Anonymous Coward · 2012-01-17 07:45 · Score: 0

Sorry, the headline should've read "Serious Non-Leadership Oracle Flaw Found". That way it actually sounds like something interesting we'd want to read.
Re:They're "patching" Larry Ellison? by Spykk · 2012-01-17 08:00 · Score: 4, Funny

If they don't affix patches to the amputation areas the horns and tail keep growing back.

Original source by vlm · 2012-01-17 05:14 · Score: 3, Interesting

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

Re:Original source by ColdWetDog · 2012-01-17 05:23 · Score: 1

Nope. RTFA.
Short answer. Very large Enterprise levels Oracle installations with multiple, interconnected databases shouldn't perform backups.
So, no problemo. Business as usual!

--
Faster! Faster! Faster would be better!
Re:Original source by rubycodez · 2012-01-17 05:29 · Score: 2

there are plenty of other ways to perform hot backups than the ALTER DATABASE/TABLESPACE BEGIN BACKUP way.
Re:Original source by Anonymous Coward · 2012-01-17 05:29 · Score: 0

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?
That CPU contains 78 fixes, one of which presumably is the one referred to in the article. So no, the problem isn't common to all the products, it is just lumped with other problems in the monthly patch announcement.
Re:Original source by stanlyb · 2012-01-17 05:31 · Score: 2

Except if you somehow are able to connect your little, low privileged and hacked database to this Goliath, then it will result in extremely long and expensive repair procedure for this mastodon.
Re:Original source by gringer · 2012-01-17 05:37 · Score: 4, Interesting
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.
--
Ask me about repetitive DNA
Re:Original source by Anonymous Coward · 2012-01-17 06:15 · Score: 0

"This Critical Patch Update contains 78 new security vulnerability fixes across hundreds of Oracle products. Some of the vulnerabilities addressed in this Critical Patch Update affect multiple products."
They release a set of (mostly unrelated) patches for many (mostly unrelated) products. The fine article talks about one of these patches.
Re:Original source by sjames · 2012-01-17 06:50 · Score: 2

That's the really scarey part. If you miss just one single database anywhere in the enterprise, even after the ruinously expensive week long shutdown, you could end up right back where you started.
Re:Original source by afabbro · 2012-01-17 08:38 · Score: 1

there are plenty of other ways to perform hot backups than the ALTER DATABASE/TABLESPACE BEGIN BACKUP way.
How?

--
Advice: on VPS providers
Re:Original source by SD+NFN+STM · 2012-01-17 09:35 · Score: 1

RMAN anyone? I doubt anyone serious still uses BEGIN/END backup...
Re:Original source by rubycodez · 2012-01-17 10:27 · Score: 1

one easy way, especially for big corporations, is to quiesce the database and take snapshot or clone with your SAN controller or host based storage manager, or don't quiesce it and just run recovery on the snapped image if you ever need it.

UNBREAKABLE by alen · 2012-01-17 05:24 · Score: 1

oops

Re:in before by joshuac · 2012-01-17 05:28 · Score: 3, Funny

The only reason Oracle has this flaw is because Microsoft's DB lineup hardly forces them to compete from a security perspective.

NTP instead of SCN? by Framboise · 2012-01-17 05:29 · Score: 2

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

Re:NTP instead of SCN? by MagicM · 2012-01-17 06:46 · Score: 2

Well, for one, NTP doesn't have a high enough resolution.
"[NTP] can achieve 1 millisecond accuracy in local area networks under ideal conditions". (Wikipedia)
"The SCN is a moving line that cannot be crossed. The line moves up by 16,384 every second" (TFA)
Re:NTP instead of SCN? by Framboise · 2012-01-17 07:08 · Score: 1

Yes but not the synchronization. The computer clock does have a much higher resolution. Also a local atomic clock precision can be obtained with GPS.
Re:NTP instead of SCN? by MichaelSmith · 2012-01-17 10:44 · Score: 1

Ha! GPS has been known to slew by a whole second on the first of january. Not nice in real time systems which rely on precise timing across a distributed system.

--
http://michaelsmith.id.au

You expose your DB server? by Bazman · 2012-01-17 05:34 · Score: 1

Who exposes their Oracle DB server to the outside world anyway? Surely its just accessible from the servers that need it. Anyone know any public Oracle DB servers? Lemme just scan the interwebs...

Of course if your front-end gets pwned then you don't want your DB server getting rooted, but hey, they got your front end server... Hopefully that will only have restricted access to the databases it needs, so an Oracle remote exploit here could let an attacker get to anything on the server...

Either way up, not a good thing... Has Larry sold his MiG yet?

Re:You expose your DB server? by Rary · 2012-01-17 05:45 · Score: 5, Interesting

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
Re:You expose your DB server? by Hulfs · 2012-01-17 05:52 · Score: 5, Interesting

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.
Re:You expose your DB server? by rubycodez · 2012-01-17 06:19 · Score: 1

you're not thinking fourth-dimensionally, Marty. All you need is a stinky reporting database accessed from web server, that happens to have read-only link to the mission critical one. Then SQL injection attack on web server to wind up the SCN number....
Re:You expose your DB server? by sjames · 2012-01-17 06:52 · Score: 1

That and even a database with read-only access to another (implying that it shouldn't be able to do any damage at all) can effectively write the SCN.
Re:You expose your DB server? by Anonymous Coward · 2012-01-17 06:56 · Score: 2, Informative

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.
Re:You expose your DB server? by afabbro · 2012-01-17 08:39 · Score: 1

Who exposes their Oracle DB server to the outside world anyway
Who says security problems are exclusive to external attackers? Plenty of internal people to worry about, particularly when you consider how many big companies outsource their IT support.

--
Advice: on VPS providers
Re:You expose your DB server? by shentino · 2012-01-17 10:22 · Score: 1

I'd say that there's a problem with a database vulnerable to this sort of cascading failure to begin with.
Re:You expose your DB server? by MichaelSmith · 2012-01-17 10:46 · Score: 1

Yeah like slashdot's 24 bit post number.

--
http://michaelsmith.id.au
Re:You expose your DB server? by hawkinspeter · 2012-01-17 11:11 · Score: 1

A dump and import into a new database isn't that tricky, but would take a bit of planning on multiple connected systems. The easiest way would be to build a duplicate system to import into, but that requires duplicate hardware.

--
You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe

security through obscurity, yet again by ChipMonk · 2012-01-17 05:40 · Score: 1

"So hackers could not exploit the bug in the meantime." Only the hackers (crackers?) that don't already know about it, and have no way of learning from their black-hat friends.

Re:security through obscurity, yet again by Rary · 2012-01-17 05:48 · Score: 4, Informative

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
Re:security through obscurity, yet again by Migala77 · 2012-01-17 23:53 · Score: 1

I have heard from someone at Oracle that for them it is forbidden to admit any Oracle software has security bugs. All public references to something that turns out to be a security bug will be removed or replaced with some non-related issue. As in TFA: "... a number of Oracle sources for this story [...] noted that Oracle licensing agreements prevented them from commenting on any aspect of their product usage". Infoworld delaying the story is not an example, but security through obscurity seems to be The Oracle Way.
Re:security through obscurity, yet again by Rary · 2012-01-18 02:46 · Score: 1

That's not what "security through obscurity" means. That's just damage control and PR. "Security through obscurity" means that the system's security is designed such that it only works if its implementation is unknown to attackers. Unfortunately, people frequently throw the phrase around whenever a situation like this occurs, further diluting the phrase to the point that it has become almost meaningless.

--
"You cannot simultaneously prevent and prepare for war." -- Albert Einstein

Here's a lolz thing to do tonight... by Anonymous Coward · 2012-01-17 05:46 · Score: 0

Lets take down all corporate databases on the planet! Winner gets a ...

Re:Here's a lolz thing to do tonight... by Anonymous Coward · 2012-01-17 09:20 · Score: 0

[CARRIER LOST]

"Interlinked" databases? by larien · 2012-01-17 05:48 · Score: 1

The issue seems to be fundamentally down to someone with DBA rights on a database issuing "ALTER DATABASE BEGIN BACKUP" which then causes an "interlinked" database to also increment its SCN; anyone know what the "interlinking" is? I'm guessing DB links but it's a bit vague on details and high on the scaremongering... FWIW, the ALTER DATABASE command will require DBA rights to implement, so I'm not seeing the apocalypse that Infoworld is punting; if you've got DBA rights, you can do lots of stuff like drop user, drop table etc, etc, etc...

Re:"Interlinked" databases? by close_wait · 2012-01-17 06:14 · Score: 2

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.
Re:"Interlinked" databases? by rubycodez · 2012-01-17 06:15 · Score: 1

there are other ways for ordinary users to ratchet up the SCN number, including the example in article given of a read-only linked reporting database having its transactions/sec pumped up
Re:"Interlinked" databases? by Anonymous Coward · 2012-01-17 06:37 · Score: 0

1. Gain access to an unpached Oracle DB Instance that is linked with the network.
2. Us the (undocumented) API call to increment the SCN to some value close to the limit. If InfoWorld is right and this can be done with an SQL Injection then this is even easier.
3. You just forced the company to drop every table and import them again
ALTER DATABASE BEGIN BACKUP is just one scenario where this can happen and maybe the only one where it happens not maliciously.

Oracle deserves you! what deception! by Anonymous Coward · 2012-01-17 05:49 · Score: 0

Spent thousands of dollars per CPU to Oracle for its *BUGGY* Database Manager Oracle.

And now, my DDBB-based services are in risk of security's menaces!!!.

My DDBB-based DATA maybe hacked! erased! corrupt! incomplete! or partially destroyed!

My DATA is financial, many millions of dollars could be lost!!!.

What deception!!!

JCPM

As usual with Oracle, the patch will be a 4GB by Nicolas+MONNET · 2012-01-17 05:57 · Score: 0

As usual with Oracle, the patch will be a 4GB download. Considering how much they charge for that junk, it's amazing those morons haven't figured out how to just simply use rpm/yum or apt.

Re:As usual with Oracle, the patch will be a 4GB by rubycodez · 2012-01-17 06:09 · Score: 1

what would that gain, it would be a 4GB .rpm or .deb
Re:As usual with Oracle, the patch will be a 4GB by Anonymous Coward · 2012-01-17 07:53 · Score: 0

CPUJAN2012 DATABASE 11.2.0.3 - size 2.4M

Using The Hacker Tool TELNET by Anonymous Coward · 2012-01-17 06:23 · Score: 1

Ca 1997 I did telnet oracleserver.myemployer.com 1521. Then typed some random characters. That ceased the connection but made the telephone ring with the DBA asking me what I did to Oracle, as it crashed. Of couse, I have zero knowledge of Oracle's binary protocol nor did I enter any passwords. Maybe the Ora listener is now a bit more robust, but then it was utter shite.

Wow!! This is coming up now? by vk2 · 2012-01-17 06:28 · Score: 2

We have been battling this since many a months now. Oracle's solution? set "_max_reasonable_scn_rate"=16384

--
No Sig for you.!

Here's the Oracle Support doc about SCNs by Anonymous Coward · 2012-01-17 06:49 · Score: 2, Informative

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

Re:Here's the Oracle Support doc about SCNs by Anonymous Coward · 2012-01-17 07:35 · Score: 0

"Longer term Oracle will be raising the upper limit from 281 trillion to an even larger number." Oh great. THAT will retain compatibility with the older releases that EVERY large enterprise is stuck with maintaining. Sounds like a win-win for Oracle from a support dollars perspective!
Re:Here's the Oracle Support doc about SCNs by Hartree · 2012-01-17 13:47 · Score: 1

"Longer term Oracle will be raising the upper limit from 281 trillion to an even larger number."
I completely fail to see how that addresses the vulnerability.
So, they make it bigger, and bump up the rate at which the SCNs can increment.
Solution. Alter a couple of multipliers in your formula for figuring out what value is now the one to propagate.
Unless there's something I don't appreciate, this does nothing to prevent a malicious use of this.

Re:SIMPLE FIX WITHIN !! by Simon+Brooke · 2012-01-17 06:55 · Score: 1

But that's just the point. Third normal form requires just one basket for all the eggs! Any DBA worth their salt knows this.

--
I'm old enough to remember when discussions on Slashdot were well informed.

baker's mini-mole by epine · 2012-01-17 07:04 · Score: 1

This has the smell of Lamport's bakery algorithm.

What is significant about the bakery algorithm is that it implements mutual exclusion without relying on any lower-level mutual exclusion. ...
I don't know how many people realize how remarkable this algorithm is. Perhaps the person who realized it better than anyone is Anatol Holt, a former colleague at Massachusetts Computer Associates. When I showed him the algorithm and its proof and pointed out its amazing property, he was shocked. He refused to believe it could be true. He could find nothing wrong with my proof, but he was certain there must be a flaw. He left that night determined to find it. I don't know when he finally reconciled himself to the algorithm's correctness. ...
For a couple of years after my discovery of the bakery algorithm, everything I learned about concurrency came from studying it.

The problem with the bakery algorithm is its assumption that you have unbounded integers.

From Lamport's comment about "On Self-stabilizing Systems":

The note contains the intriguing sentence: "There is a complicated modified version of the bakery algorithm in which the values of all variables are bounded." I never wrote down that version, and I'm not sure what I had in mind. But I think I was thinking of roughly the following modification ...

A distributed ratcheting attack against the backery algorithm is very interesting to nerds in the know. Someday I'd like to sue someone who interrupted me with a nuisance phone call for the value of what I was just about to write down. Lamport could argue for 8 figures.

Re:baker's mini-mole by fusiongyro · 2012-01-17 08:21 · Score: 1

What's going on here is actually MVCC. The idea here isn't to implement mutual exclusion so much as to ensure that concurrent writes can occur but nobody sees information outside their transaction; each transaction gets an ID assigned to it which is 1 + the previous transaction ID (in an idealized, serializable exclusion state) and your transaction can see any information with your ID or a lower (but committed) transaction ID. Transactions begun after yours can see your effects only after you've committed, and you can't see effects from transactions started after yours, even if they are committed.
Now, it's really only an "attack" if you have both 1) a way to inflate the number quickly and 2) small maximum values. It happens that these conditions are met with Oracle only because there's a bug in the hot backup facility, and the database link facility lets you pump the value across the cluster. This isn't a problem with PostgreSQL, because the version comparison uses modular arithmetic that permits wraparound and the VACUUM facility marks old transactions with an "older than everything" version that is special-cased in the comparison. So if the relationship between MVCC and the bakery algorithm is close, it wouldn't take a very big tweak to make the bakery algorithm resilient against this problem.
Re:baker's mini-mole by Hartree · 2012-01-17 09:08 · Score: 1

The backup utility is just one way to do this. A malicious use of it wouldn't be bound by that.
Assume you've subborned a low level DB by whatever means and have control of the machine it's running on.
Now that you know that a simple SCN bump can propagate you just have to either forge that, or get the local DB to send your calculated value. You already have the credentials for it in the DB itself. It'd take some work to make it so a script kiddy could do it, but might not be prohibitively difficult.
As an aside, an attack on the extant implementations of the Bakery Algorhithm would be a very interesting thing.
(I'm by no means qualified to analyse that one off the cuff. It seems to me it'd depend a lot on the way information is being transfered and whether the numbers could be subborned at remote systems. Then again, I'm by no means a guru on that. Just a former DBA.)
Re:baker's mini-mole by fusiongyro · 2012-01-17 10:37 · Score: 1

(Never seen this word "subborn" before.)
I read the article, and I must have missed mention of any other way than through ALTER TABLE BEGIN BACKUP to get the SCN to increment dramatically. I think it would be hard to do a better job than than Oracle's bug, which according to the article could achieve a rate of millions or billions of increments per second, by simply running a trivial transaction in a loop. Could it be done? Maybe, but that could be a lot of work.
Now, my impression is that this is a really obnoxious bug that will bite their highest paying customers disproportionally, but not that this is a particularly onerous security problem. The prerequisites for using this to perform a DOS are pretty big. Oracle's protocols are not particularly open. The SCN is buried in the database pretty deep; there's no way for an admin to directly access it. So you either have to trick an instance into manufacturing large values for you with a loop, or you'd have to reverse engineer the database link protocol. Even assuming you've done that, you having to insert yourself into the database's network. If you can afford enough Oracle licenses to run an Oracle cluster, you're probably paying for Oracle DBAs and systems administrators that know how to operate a firewall. Your Oracle is probably not listening on the public network. I'm saying that in all but the most pathologically embarrassing circumstances, you already have to own machines on this network to take down Oracle this way, which means your security was already breached before you could use this to breach the security.
Re:baker's mini-mole by Hartree · 2012-01-17 11:10 · Score: 1

From the article on page 3: (Though they don't give the actual commands, they should be pretty straightforward to figure out.)
"But the risk of incrementing the SCN via the backup bug is not the only cause for concern. Perhaps the most important part of our finding is that the SCN can be incremented by anyone who can issue commands on an interconnected database."
Note the phrasing: "anyone who can issue commands on an interconnected database".
Not an admin, not a role with backup rights, or anything specific. Just ability to issue commands. It may be inaccurate, but I suspect this one needs no special privileges above a normal user.
In fact, the ATT incident for 1999 mentioned in an earlier post was using the default "bob" account to exercise the bug.
Re:baker's mini-mole by Hartree · 2012-01-17 11:38 · Score: 1

Gah. Had a mind fade. (It's been a few years). Somehow got "bob" tangled up with scott/tiger in my mind.
It looks like it may require the DBA role. Not sure it takes that. But still, it means you only have to get it on a low level server and it can propagate the error to any other that's linking to it. Even if the links are read only.
Re:baker's mini-mole by fusiongyro · 2012-01-18 03:08 · Score: 1

Every transaction that results in a change will increment the SCN, which is what the article is implying. This is a big part of databasery, so of course there will be unprivileged (i.e. non-admin) users who can increment the SCN through the usual manner of running transactions. My point is that with the ability to run transactions but without the ability to run ALTER DATABASE BEGIN BACKUP (i.e. a non-admin user with write access) it will be hard to beat ALTER DATABASE BEGIN BACKUP at the game of incrementing the SCN. Certainly if you are running that quantity of transactions, odds are good you are already DOSing the database without the SCN soft limit bug even being involved.
This right here is a great example of why I think software security as a field is largely bullshit. The amount of work and luck it would take to "exploit" this is such that by the time you've done it, you've already exploited all sorts of other things, including pre-existing poor security. It's not a security problem. Security is just a great way to get everyone's blood pumping.
Re:baker's mini-mole by Hartree · 2012-01-18 03:54 · Score: 1

Are you even reading the same article that I am?
It took me about 5 minutes to find the "undocumented and hidden" commands that let you directly change the SCN. (I'm not posting it, but you can google it easily if you like.)
For the method I'm thinking of, you need DBA rights. But if you've rooted a machine, that's not much of a barrier. You can change and then change back the sys password with known means and standard tools that are present up to somewhere in the 11 series. (And even that isn't a barrier, as you can add the tools back in even in 11).
I won't give a recipe for how to do it in an open discussion, but you can get the info easily on the net. 10 minutes of google-fu is not a significant security barrier.
You can calculate the value needed from the current time and multiplication.
Further, like many exploits, only one person needs to be good enough to develop the exploit. Then it can be packaged in a script that any random can use.
This one truly is pretty trivial to exploit. And with a bit of imagination (certainly nothing we haven't seen in the system crackers) you can still do it even if Oracle patches the most obvious routes.
Yes, there's a lot of hype in security. I've railed against it myself. But, the attitude "this is too hard" leads to a lot of compromised systems. I've had to clean up too many compromised systems due to that complacency.
If what you say was true, such things as stack smashing and SQL injection that compromise systems all the time would never have become a problem. They all had to have someone work out the particulars so that they were good enough to displace previous attack methods.
Go subscribe to Bugtraq or VulnDev for a while. It'll be an eye opener for you.
Re:baker's mini-mole by fusiongyro · 2012-01-18 09:20 · Score: 1

But if you've rooted a machine, that's not much of a barrier.
That's my whole point. You've already rooted the machine. You can do anything. The bug is irrelevant. You can just shut the database down. You can delete the cluster. Anything. This bug has nothing to do with it.

Further, like many exploits, only one person needs to be good enough to develop the exploit. Then it can be packaged in a script that any random can use.
Your pre-packaged exploit is unable to use this bug to root the machine, and furthermore depends on the machine being rooted already to work. Not an exploit.

the attitude "this is too hard" leads to a lot of compromised systems. I've had to clean up too many compromised systems due to that complacency.
In order for this to be a problem, you already have to have failed at setting up a firewall or had compromised security elsewhere. I don't disagree with you in general, I'm just saying, this is not a security vulnerability, by the above.

If what you say was true, such things as stack smashing and SQL injection that compromise systems all the time would never have become a problem.
I most certainly did not say that, and in order for that to be a consequence of my argument there would have to be a dependency on a pre-existing root exploit or other privilege escalation mechanism for stack smashing and SQL injection to work. But there isn't, which is what makes this completely different. You already need to have compromised security to use this bug to compromise security.
If half of you security morons would take enough CS to learn the tiniest bit of graph theory and find out what a DAG is, I wouldn't find myself having this argument constantly.
Re:baker's mini-mole by Hartree · 2012-01-18 12:52 · Score: 1

If it makes you feel better to call me a moron, great. I find looking at pictures of cute kittens helps my day. YMMV.
I think you've misunderstood the impact of this bug.
The threat is not that controlling one machine can let you delete that one node or shut the instance down. It's that having taken control of that node, which may for very good reason be in a less secure area (physically and network wise) than a main data center, you can then use it to not only lock up the systems in that protected center but make it so they have to be rebuilt. Regardless of the security in between the compromised machine and the protected systems as long as they use DBlink to send info to each other. Even via read only links.
This is effectively an escalation of your access to be able to take down more sensitive systems you do not already have access to.
Security is not one layer that all depends on. It's a series of barriers. This allows you to punch through the inner layers if you gain a foothold in an outer one.
Oh, and I'm not a "security type" any more. I have no great stake monetarily or professionally in this. I'm working in an unrelated field these past few years.
More importantly, I was a DBA who had to run linked databases under Oracle for financial companies, where downtime was extremely expensive. A fault that allows one compromised system to be used to damage a much more highly protected system indeed is a problem.
Compromised systems indeed are going to happen. Maybe it shouldn't be that way, but that's reality. Part of thinking in depth is minimizing the fallout when a system is compromised.
If you've been having this argument regularly you might consider the tiny possibility that there might be some of the misunderstanding on your side.
Is your comment about a DAG just a snide way of saying "you can't get there from here" in terms of reachability (I'd say that's a missapplication of it as a model) or do you have something else in mind?
Or is it just a good excuse to end the discussion?
Re:baker's mini-mole by fusiongyro · 2012-01-19 05:05 · Score: 1

First, I'm sorry about being a dick. I think not being able to hit Wikipedia yesterday really soured my mood. Yes, that's what I meant about DAGs, but it was just a dick thing to say.
So, you make a good point, and I'm calm enough to see it today. I still think the article oversells the danger of this bug. We don't use dblink or hotbackup at my site (we're transitioning away from Oracle too). My friend sysadmins for a company that has a much larger clustered Oracle instance, and were using this hotbackup facility. Their DBA noticed the problem a while back and took steps to counteract it. They're also not using dblink.
I suppose there's a lot of personal bias in my perspective here. I haven't had to deal with large corporations with huge, interlinked Oracle instances. For them this could be an issue, but security is a problem that grows exponentially. While applying the patch is something that should be done, I think they can effectively counteract the problem by restricting access to hot backup, maintaining better control over their databases as a whole and reducing use of dblink.
That said, handling anybody's database situation is not an easy task. Where I work, there are only a few hundred employees, but enough of them are engineers and programmers that there are many unaccounted-for databases. Even worse, when a developer sets up a database, they're much less likely to keep it up-to-date as long as it's working. This situation is ripe for this kind of threat, but I say this situation is already bad enough that this is just icing on the cake.
Re:baker's mini-mole by Hartree · 2012-01-19 10:35 · Score: 1

No worries. My own reply was a bit more tart, but I got distracted by a customer for a few minutes and then rewrote it.
Yep, there's an awful lot of "OMG! Dire Threat! So you must buy our magic security dust" out there.
DBAs (or sysadmins) catch a lot of problem due to the differing priorities in a company.
The developers and engineers are judged by getting product ready and aren't too likely to get in major trouble over a DB or machine security problem. And they generally aren't DBAs or have that mindset that forgetting to do the equiv of changing the oil and filters can get you into problems. (It's slashdot. We've gotta have a car analogy.)
The DBAs/sysadmins have to live with any oversights of the programmers/engineers in security/stability in their code or systems, so they catch it a lot.
That's why alt.sysadmin.recovery was so popular. There's a reason why I don't do admin work anymore. ;)
As you say, fixing the live backup bug will help with the inadvertant cases. And monitoring SCN growth will help with all the cases. A big thing is that now this is known, if it happens it can be recognized for what it is and that'll make recovery a lot less of a problem even in the worst case.

That's a pretty bad bug. by Hartree · 2012-01-17 07:05 · Score: 1

Or, actually, a family of them and at the level of basic architecture.

Get into a low level database via some poorly secured login (or conceivably a SQL injection. Maybe. Not clear if that's possible) and take down any DBs that are linked just by snapshots.

And the recovery can be so bad as rebuilding every single linked instance (and don't miss one, or you fail.) and reimporting the data.

Ouch, ouch, ouch. I can think of all sorts of mayhem that could be done with this by someone with destructive intent.

They say it's only a problem for large installs, but let me assure you there are a lot of places with 3 or 4 linked instances that can't easily withstand the downtime for complete rebuilds of everything.

Let alone that have DBAs cluefull enough to immediately figure out the drastic steps need to recover without several failed first tries.

And, the kicker, if you have ancient legacy systems hooked up, they're still vulnerable as there won't be patches for it. And, though the headroom gets increased by the fix, the basic flaw is still there if you have linked unpatched systems.

Now the question is if there's any way to unlink the SCNs and still have it do the same function. Or at least make it so one DB can't lie about what its SCN is.

Re:That's a pretty bad bug. by Anonymous Coward · 2012-01-17 07:43 · Score: 0

"Now the question is if there's any way to unlink the SCNs and still have it do the same function. Or at least make it so one DB can't lie about what its SCN is." Sure. Don't take the higher SCN value from the remote DB. Track the SCN's individually when performing inter-db operations. This whole design of escalating each other's SCN's just for the purposes of synchronization is just plain stupid. Especially when the SCN has a hard-coded maximum.
Re:That's a pretty bad bug. by Hartree · 2012-01-17 08:08 · Score: 1

"This whole design of escalating each other's SCN's just for the purposes of synchronization is just plain stupid. Especially when the SCN has a hard-coded maximum."
That was kinda my thought, but didn't want to say that was the fix as there are always complications. Dog knows what all they've got depending on their particular format and rules for the SCNs.
The big thing would be figuring a way to do it so that existing installs can be made compatible with that without requiring rebuilds, or at least that all of them don't have to be done at once.
(Disclaimer: it's been nearly a dacade since I did Oracle to any extent.)

Can anyone really comment on this? by tburke261 · 2012-01-17 07:07 · Score: 1

So at this moment I've scanned through all of the comments and haven't seen anyone who actually works with a sizable Oracle deployment make any sort of informative comment. So, Oracle DBA's, is this silly InfoWorld fear mongering or something you and your organization (or a larger org) should actually be seriously concerned about? To me it seems like under the right conditions this could bring an entire org's OracleDB structure down, but then again, I've never actually worked with it in production....

Re:Can anyone really comment on this? by Anonymous Coward · 2012-01-17 10:21 · Score: 0

Oracle just released the lengthy explanation quoted above, Note ID 1376995.1, a patchset for this (work-around more like) and tool to determine the SCN's "closeness" to the limit, so it would seem that they take it seriously - need any other "authority"?
RO

Very old problem by philj · 2012-01-17 07:34 · Score: 1

Re:Very old problem by Hartree · 2012-01-17 08:22 · Score: 1

Standard Oracle. They hack up a patch so you can diagnose the problem but don't fix the base cause.
If they're still like they were in the mid 90s, they may blow some smoke about it being fixed in the next release, but never really fix it.
And AT&T was paying for what ultraviolet level of metal support?
Guess I can't blame them to much when it's so deep into the system.

Re:in before by Anonymous Coward · 2012-01-17 07:37 · Score: 0

you kidding right? Hah Oracle is
swiss cheese compared to MS SQL

SQL to check your database by SD+NFN+STM · 2012-01-17 10:02 · Score: 1

If you're worried... then check out your SCN with this SQL:

su - oracle
. oraenv
sqlplus "/ as sysdba"
column GET_SYSTEM_CHANGE_NUMBER format 999,999,999,999,999,999,999
select DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER from dual;

Millions or Billions... no problem.
If you're starting to get close to 281 Trillion (actually 281,474,976,710,656)... time to panic. Remember, that's a US Trillion... not a UK Trillion:

Re:SQL to check your database by EETech1 · 2012-01-17 19:21 · Score: 1

Any reason you have to use 21 formatters for a 15 character long number?
Just curious!
Cheers:)
Re:SQL to check your database by SD+NFN+STM · 2012-01-18 02:18 · Score: 1

Too lazy to count... :-D
Re:SQL to check your database by EETech1 · 2012-01-18 05:59 · Score: 1

:)
Would that cause it to print any number out to 21 digits, or would it only spit out the digits used?
(Now updating my linkedin profile to include Oracle DBA)
Cheers!

Old but gold by cormandy · 2012-01-17 10:05 · Score: 1

Scott/tiger

Oh ... Well .. That? ... Likely Not by Anonymous Coward · 2012-01-17 16:51 · Score: 0

nfoWorld is a publisher.

Oracle is a Business ... with people who know how to code, i.e. program in the old days addage.

So, lets get this straight. InforWorld ... a publisher with no known ability or abilities of its employees as actual programmers now asserts that Oracle has a "Bug" and heafty one at that!

Oh .. Now I get it! The InforWorld "Scientists" discovered a "Typo" in one of the schema of Oracle DB! Oh ... and this ... Type ... wreaks all havoc on all things Oracle.

Hardy har har.

Me thinks the "response" from Oracle to InfoWorld will be an attonery with papers in hand explaining the Oracle lawsuite against InforWorld.

At which point InfoWorld Execs will shit in their pants and cry like babies at the throught of having their pinus' cut off!

Ta Ta

Unbreakable! by Sean · 2012-01-18 10:14 · Score: 1

Can't break it. Can't break in.

SCN isn't 'time' by splutty · 2012-01-19 02:21 · Score: 1

SCN is a number that gets increased *per transaction*, so is in a way related to time, but never in a 1-on-1 relation.

--
Coz eternity my friend, is a long *ing time.

This Wouldn't Happen On NoSQL. by feuertod · 2012-01-20 03:29 · Score: 1

MongoDB is web scale! :P

Slashdot Mirror

Serious Oracle Flaw Revealed; Patch Coming

100 comments