In my previous blog, I tried to explain why the fundamental Oracle flaw is dangerous. On the other hand, in my tests I couldn't find a way to pass a higher SCN to a target DB to crash it. Since then, I'm trying to verify that this flaw can be can exploited. Here's a short video of one of my tests:
So what's the next move? According to my first impressions, the latest CPU Patch solves the SCN problem. Patched database detects big SCN jumps and denies remote transactions. So I'll repeat myself again: Please apply the CPU as soon as possible.
The problem with denying remote transactions is that the transaction activity could be valid. It is just the SCN numbers for the two databases are too far apart to allow the connection.
ReplyDeleteIMHO -- Mark D Powell --
Mark, you may be right. I'll comment about it after I make more tests on the patched databases.
DeleteYou've crashed the db - OK an ORA-600 with a crash will get everyone's attention. But the more serious question is, what do you have to do to get to where you have to reload the db because you've used 500 years of SCN's? Without the 11.2 alter database begin backup bug, this doesn't seem worse than any other DOS attack, and would be more difficult to distribute?
ReplyDeleteWell, I wouldn't like to get a call at midnight and hear that our main production database is down. As I demonstrated in the video, it's possible even you do not hit begin/end backup bug.
Delete