The protective wrapping around the programming language used to write procedures and commands in the Oracle Corp....
database isn't as ironclad as some might expect. In fact, one expert claims it can be unraveled to access sensitive data.
That warning comes from Pete Finnigan, an author and keeper of a blog on the subject of Oracle security.
He recently released a white paper (.pdf) illustrating how to defeat the protective layer around the Procedural Language extension to Oracle's Structured Query Language (PL/SQL), and gave a presentation on the subject at the Black Hat USA 2006 conference in Las Vegas earlier this month.
Many companies wrongly assume that the wrapping mechanism used for PL/SQL is as strong as standard encryption, he said, but his presentation was designed to snap database administrators (DBAs) out of that false sense of security.
"The biggest problem is that a lot of companies have used PL/SQL to implement business logic in the database and have a false perception that their trade secrets and intellectual property is safe if the code is wrapped," Finnigan said. "DBAs should be concerned because application logic can be made available, critical data such as keys used to encrypt credit cards can be found and the cards stolen. There are many issues around this."
Finnigan said he doesn't see the weakness as a software vulnerability that can be easily patched. Rather, he said it's an inherent problem with the design decisions Oracle made a long time ago. Specifically it chose to use an abstract data type called the Descriptive Intermediate Attributed Notation for ADA (DIANA) as the obfuscation tool to hide intellectual property written in PL/SQL, and more recently chose to use a simple algorithm in version 10g of the database to encrypt the PL/SQL source code.
While he perceives the issue to be a weakness in the programming language, Finnigan hasn't seen any direct evidence of hackers trying to turn the exploit into a big attack.
"I have not seen evidence that bad guys are using unwrappers, except for indirect knowledge of a hacker a few years ago who unwrapped all of Oracle's built-in packages and posted them to the Net," he said. "I do know that most security companies involved in Oracle security products and services are using unwrappers to find problems such as SQL injection and cross-site scripting bugs, and also to analyze critical patch updates released by Oracle to understand what has been fixed and how the original bug could be exploited."
After reviewing Finnigan's white paper, an Oracle spokesman agreed that DBAs should never consider wrapped PL/SQL to be a substitute for encryption.
The wrapping mechanism, which turns data into numbers and symbols to make it harder to see the source code, is meant to be another wall between sensitive data and prying eyes, but was never meant to be a form of encryption. He said that point is made clear in a technical page on Oracle's Web site.
"Although wrapping makes reverse engineering difficult, we don't recommend it to hide passwords and the like," the spokesman said. "This is obfuscation, not encryption."
Despite the weakness, Finnigan said DBAs should continue to use the wrapping mechanism, since it's better than nothing at all. That said, he added, "If you are a big enough customer of Oracle and you would like to use PL/SQL and keep your intellectual property safe, then ask Oracle for a real method for securing PL/SQL."
Finnigan's Black Hat presentation wasn't the only one focused on Oracle security. Alexander Kornbrust, database security researcher and business director at German firm Red-Database-Security GmbH, gave a presentation on how attackers could use rootkits to compromise an Oracle database.
David Litchfield, managing director at UK-based NGS (Next Generation Security) Software Ltd., didn't use his stage time to focus specifically on Oracle flaws as he has at past Black Hat conferences. But he did criticize the database giant for not being as attentive to security as it should be, and called database security "the biggest problem we face in IT today."
Most of the Oracle security criticism has been directed toward the vendor's patching process. Its quarterly Critical Patch Updates (CPUs) are typically followed by reports from security researchers of flaws not being fixed as advertised. The Redwood Shores, Calif.-based vendor has also been accused of sitting on vulnerabilities that are more than a year old, and of releasing patch bulletins that are hopelessly difficult to decipher.
In a recent interview, two of Oracle's security directors admitted that a vast array of platforms and mountains of source code can make for some patching mistakes, though they don't necessarily agree with some of the flaw findings independent researchers release to the public.
Don Burleson, Oracle expert and CEO of Kittrell, N.C.-based Burleson Consulting, said Oracle security is much stronger than some might suggest and that the greatest threat to database security comes from DBAs who often make configuration mistakes, unknowingly leaving their systems open.
"Just about every single one of the vulnerabilities published about Oracle has been something that someone on the outside without a user ID couldn't exploit," he said. "When I see these flaws, I find that it doesn't apply unless the DBA has configured something in a way that allows the vulnerability to exist. These vulnerabilities speak more to faulty DBA practices than any fault of Oracle."