Oracle Security Commentary

[back]

Thoughts on whatever's going on in the Oracle security world.
[David Litchfield]

[17th November 2005] On Oracle worms
A few weeks ago someone posted half a worm to the full-disclosure mailing list. The idea of an Oracle worm has always been bubbling under the surface but has routinely been dispatched with a "there's no point in writing an Oracle worm because they're all protected by firewalls" attitude. What is clear is that not every Oracle server is protected by a firewall - there are plenty out there that are exposed. In a few weeks, when the research has been completed I'll post the results on this - just how many Oracle servers are out there, exposed to all and sundry. Besides this, I'm surprised that no-one has yet pointed out that the extproc flaw is an ideal vector for a worm. The worm could call extproc remotely, launch libc or msvcrt.dll, call the system function and tftp down a copy and so on. Touch wood this won't become a self-fulfilling prophecy. This is one of the strongest arguments to ensure you're patched against the extproc flaw or for even better protection disable external procedures altogether if your apps don't need them.

[16th November 2005] Oracle on XP with Simple File Sharing a.k.a. Everyone can be a DBA
Whilst writing the Oracle chapter for Special Ops in 2002, I came across a curious flaw that allowed a remote attacker to gain DBA privs if the database server was running on Windows XP. I've finally sat down and worked out why it works. Have a read why here.

[15th November 2005] Unpatched for 3 years and 10 months!
So whilst looking into old bugs I noticed that Oracle 8.1.7.4 - fully patched - is still vulnerable to the old extproc flaw! This hole allows a remote attacker with no user ID or password to gain control of the database server. Why on earth is this still unpatched? Seeking an answer to this I found the following in Alert 57:

Currently, due to architectural constraints, there are no plans
to release a patch for versions 9.0.1.4, 8.1.7.4, 8.1.6.x,
8.1.5.x, 8.0.6.3, 8.0.5.x, 7.3.x, or other patchsets of the
supported releases.

What? Wait a minute. They managed to fix the flaw and deal with the same "architectural constraints" in other versions - why not 8.1.7.4? A cynical observer might conclude that Oracle have deliberately left this unpatched in order to improve the chances of their user base upgrading to a version of Oracle that has a patch and having to part with more money. Oracle customers running 8.1.7.4, or any of the versions listed above would be right to feel indignant. This is exactly the kind of thing I was referring to when I posted this open letter.

[14th November 2005] Oracle Security Features vs. Oracle Security Vulnerabilities
I'm in the middle of comparing security features of various databases at the moment for a whitepaper and I'm seriously impressed by the arrary of features built into Oracle. However, if your code is as insecure as Oracle's is, then it doesn't matter a jot how many security features you have: they can all be subverted. When Oracle get their code right, then they'll be considerably closer to the "Unbreakable" they once told us about.