X
Business

Oracle from unbreakable to unpatchable

In a twist of irony, the proof-of-concept shellcode produces a sample text file on the server called "unbreakable.txt" with the string "ARE YOU SURE?" inside. When Larry Ellison boldly proclaimed Oracle was "unbreakable" to the world, the crackers of the world boldly responded with "root".
Written by George Ou, Contributor

When people complain about patching two or three vulnerabilities every month on their Windows machine, I can't help but chuckle when I think about the dire situation Oracle users are in.  Oracle, which has always bragged about being "unbreakable" and "never breaks" just released its quarterly critical patch update composed of fixes for 82 critical vulnerabilities in nearly every Oracle product.  Many organizations using Oracle leave themselves exposed to these fresh exploits for months. Unfortunately, the most critical vulnerability for the Oracle PL/SQL Gateway, which allows a hacker to gain full administrative control of a back-end database from anywhere on the Internet, was left unpatched -- even though it was disclosed to Oracle in October of 2005.

David Litchfield, who discovered the bug and reported it to Oracle, demonstrated the vulnerability at the Black Hat 2006 Federal Briefing in Washington DC.  Litchfield then posted this workaround so that organizations can mitigate the vulnerability, but blasted Oracle for not making a patch available for this quarter's patch cycle which means Oracle users will be exposed for another 90 days.  Although the proof-of-concept exploit code wasn't released by Litchfield, it's only a matter of time before some smart hacker reverse engineers the workaround if they haven't done so already.  Any organization using Oracle PL/SQL Gateway should apply Litchfield's workaround as soon as possible and also apply any of the other 82 critical patches that pertain to them.

To make matters worse, another critical flaw called DB18 affecting Oracle database 8i/9i/10g discovered by Imperva was fixed in this quarter's mega-patch two months after the flaw was reported.  This particular bug is so nasty because it affects every Oracle database in the past five years and allows a hacker to escalate their privileges from guest to database administrator.  Since Oracle deployments are complex with many critical dependencies from application servers that might break during an update, it often takes weeks or more to plan and test an Oracle patch of this scope.  As a result, many organizations using Oracle leave themselves exposed to these fresh exploits for months.

If you thought this was the end of it, an XML database component buffer overflow proof-of-concept exploit in Oracle Database Server 9i/10g was released to the Internet yesterday.  This particular flaw allows a hacker to launch shellcode on an Oracle database server to obtain complete control.  In a twist of irony, the proof-of-concept shellcode produces a sample text file on the server called "unbreakable.txt" with the string "ARE YOU SURE?" inside.  When Larry Ellison boldly proclaimed Oracle was "unbreakable" to the world, the crackers of the world boldly responded with "root".

This would almost be funny if this wasn't for the fact that a significant chunk of the world's most sensitive data resides on Oracle databases.  The reason this isn't more commonly known is because it's difficult for ordinary computer users to relate since Oracle is something that's usually tucked away in a server room somewhere.  Hackers who do hack into Oracle usually never do it for bragging rights by defacing a website but do it for serious financial gain by stealing critical information.  The last thing these hackers want is notoriety because it makes it harder to do business.  Unfortunately, this lack of outcry has allowed Oracle to continue on with these quarterly mega-patches while spouting their "never breaks" slogan.  Every CIO or IT manager who pays hundreds of thousands of dollars a year in Oracle licensing fees should be ringing Oracle's phone off the hook because they're certainly not getting their money's worth.

Editorial standards