Oracle Corp. may be baking more secure code into its new products, but some experts say that doesn't help enterprises using older programs that are riddled with vulnerabilities.
Those experts add that the vendor's patching process still leaves much to be desired, as it often ignores key flaws for months and even years, leaving enterprise databases open to a variety of attacks.
The critical patch update (CPU) the Redwood Shores, Calif.-based vendor released last month is a good example of the inadequacies, said Alexander Kornbrust, database security researcher and business director at German firm Red-Database-Security GmbH. The update patched 36 flaws in a variety of products, but some fixes were incomplete and a long list of other problems went unaddressed.
"Overall, there are 130-140 open security issues if you tally everything found by different researchers," he said. "Oracle's code and product quality is getting better, but they still take way too long to fix vulnerabilities. In my view, a year-old flaw is unacceptable."
Agreeing with that view is Pete Finnigan, author of Oracle Security Step By Step and keeper of a popular blog on the subject.
In an e-mail exchange, he said Oracle is making a better effort to improve code in newer products, but they're not working hard enough to fix code weaknesses in older programs. He said that's a problem because many Oracle customers aren't using the latest and greatest programs. "Most of those I talk to are not on 10g release 2," he said. "The focus should be on fixes for versions of Oracle that the general customers are using."
Finnigan also wasn't impressed that the fixes in the April CPU were delayed for certain platforms. He said the patch download page noted that for some platforms fixes wouldn't be available until May 1 or May 15. "This is not a quarterly patch cycle," he said.
Oracle has also been criticized for releasing partial security fixes for certain issues. Kornbrust said one of the incomplete fixes in the April CPU affects the Oracle Spatial utility. In an analysis on his Web site, he said one of the fixes for Oracle 184.108.40.206 is incorrect and that one parameter in the spatial package isn't properly sanitized, meaning sensitive data isn't properly removed or quarantined.
David Litchfield, managing director at UK-based NGS (Next Generation Security) Software Ltd., said on the Full-Disclosure electronic mailing list hosted and sponsored by Danish vulnerability watcher Secunia that the April CPU endeavors but fails to address a problem dating back to April 2004.
Since then, Litchfield said there has been a pattern where Oracle tries to fix the problem in a CPU, he finds the fix is inadequate and the company tries to fix it again in the next CPU.
"I was told the April 2006 CPU contained a fix, but it [is] still vulnerable," he said. "It is unfortunate that Oracle did not take the opportunity to fix the flaws the first time around. It is amazing Oracle didn't fix them the second time around. It is disgraceful, in my opinion, that they didn't fix them properly the third time around."
A familiar story
For Oracle, criticism over its patching process is nothing new. The company's CPUs are usually followed by third-party warnings about flaws that either went unaddressed or weren't fixed properly.
Litchfield has been a particularly vocal critic of the database giant's security efforts. When he criticized Oracle's patching efforts following the January 2006 CPU, Oracle fired back, saying it was "disappointed" Litchfield had revealed information that could be used to exploit the flaw in question.
In past interviews, Oracle CSO Mary Ann Davidson has acknowledged her company's patching process isn't perfect, but that it has taken steps in the right direction. One example she gave was the company's decision to have a quarterly patch update database administrators (DBAs) could plan around.
Indeed, DBAs have expressed support for the quarterly cycle. But complaints over slow patching seem to have increased in recent months.
Oracle did not immediately respond to a request for comment for this story.
Kornbrust said the company could alleviate a lot of criticism by simply improving communication. For example, he said, the CPU bulletins could better explain which flaws are critical as opposed to issues DBAs can address without having to apply a patch.
"Patch information that comes from Oracle is very complicated," he said. "This latest patch is rated critical. The problem is that if one issue is critical, the entire update is deemed critical. But for DBAs some flaws are more critical than others, depending on their infrastructure."
In these cases, he said, DBAs need information to help them decide when to apply a patch and when it's better to apply a workaround.
Should information security pros be wary of endorsing the use of Oracle products in their organizations until the database giant solves its communication and process problems? No, said Jonathan Eunice, an analyst at Nashua, N.H.-based Illuminata Inc.
"All large, complex products have bugs, whether it's the DBMS or the applications, these are packages on which customer data depends, so one doesn't just make change willy nilly," he said in an e-mail exchange. "Any problems need to be carefully understood, and any proposed changes need to be carefully tested. That takes time."
The time might be longer than everyone would like, he said, but it wouldn't be helpful to partially fix one bug and create several more in the process, all for the sake of speed.
"So while Oracle isn't really unbreakable, neither do I find them remarkably bad," he said.