Application Security // Database Security
11/30/2011
06:58 PM
Connect Directly
RSS
E-Mail
50%
50%
Repost This

Researchers Say Oracle Leaves Databases Needlessly Vulnerable

As SQL injection attacks and other advanced threats targeting database assets gain traction, researchers complain that Oracle's other application efforts are distracting the company from shoring up database security

Is Oracle just paying lip service to database security? Some researchers within the database community think so, complaining that as the software juggernaut has grown with acquisitions such as the blockbuster Sun deal it hasn't maintained enough resources to securely develop database products and resolve vulnerabilities disclosed by researchers in a timely fashion.

"I would say easy fixes get done pretty quickly, within three to six months, but things that are harder and need some changes in architecture or have an impact on customers where customers have to make some changes to their products, to their software that uses the databases, those things don't get done in the CPU," says Alex Rothacker, manager of Application Security Inc.'s research arm, TeamSHATTER. "We have a vulnerability disclosed where basically we can brute force any users password and we reported this two years ago and they haven't fixed it yet."

It's a complaint lodged by many researchers, who say that even as Oracle publicly states it wants to work with the research community to fix database issues, it isn't putting its shoulder into the effort. For its part, Oracle hasn't stepped forward to defend itself. The company did not respond to questions for this article.

But the numbers show that over the past several years, the proportion of quarterly critical patch updates for Oracle database products has diminished considerably over the last two years.

While some might come to the conclusion that there are fewer updates because Oracle's products are getting more secure, researchers say this trend has occurred simultaneously as the window between disclosure of vulnerabilities and patch releases for them has grown wider.

"They respond immediately and say 'Thank you very much for the information' and so on, but it sometimes takes more than a year to actually release a patch," says Slavik Markovich, vice president and CTO of database security for McAfee. "I get the feeling that they don't invest enough or have enough people working on this so it takes a long time to patch." In the meantime, too, new database products--some of them security related, even--are released with the same type of vulnerabilities that researchers have been alerting Oracle to for years.

"The more troubling thing is that the vulnerabilities that we're finding and the vulnerabilities that they are fixing are still commonly in brand new software or even worse in brand new security software (like Database Vault and Enterprise Vault)," says Josh Shaul, CTO of AppSec. "It's hard to believe that they're taking security very seriously when they continue to put new vulnerable software out there and continue to not to deal with some severe vulnerabilities that we've alerted them to a long time ago." Of course, the tiff between Oracle and the research community is a difficult 'he said, she said' affair to untangle from the bystander's perspective. Even the analysts don't get to see what's happening under the covers.

It is clear that there have been fewer database security-related patches being pushed out through the quarterly CPU, there is no doubt about that," says Adrian Lane, analyst with Securosis. "Are they holding back on stuff that they have been advised about? I don't really know because I'm not always privy to what gets disclosed to Oracle in advance of them actually fixing it."

Researchers generally won't disclose the details of their vulnerabilities until patches are released and Oracle rarely comes from behind the PR wall to defend itself. It's a frustrating scenario for some researchers to deal with, one which database security guru David Litchfield circumvented somewhat in 2010 when he released the details of a zero-day, privilege-escalation vulnerability.

According to several researchers, Oracle's lack of response to issues is less a process issue than it is a resource problem. As the company has extended its reach far beyond the core database platforms that put it on the map some decades ago, it may be stretching its resources more and more thin, says Amichai Shulman, CTO of Imperva.

"The problem is not with the process but with the resources and focus. They've introduced numerous new product line without substantially increasing the amount of resources allocated to the patch generation process in a proportional manner."

But according to him it isn't even the length of time for patches to be released that is the big issue. It is also the close-to-the-vest attitude the company takes once it actually releases updates that causes issues for users.

"Another problem with Oracle’s process is that they don’t provide enough detail about vulnerabilities. This means security professionals are in the dark whether they should patch the issues or not," Shulman says. "Oracle argues that if they gave more color about the holes, hackers would have better information on what to hack. The problem, of course, is that hackers know what to hack. It always behooves vendors to provide as much detail as possible to help prioritize what to fix."

Given the fact that many organizations struggle with database patches anyhow--the International Oracle Users Group reports that 63 percent of organizations say they are at least once CPU cycle late for deploying patches--details about every patch could really help their security team and supporting vendors put mitigating defenses in place until a patch is deployed.

"If Oracle were to work more closely with security vendors on disclosure of vulnerability details then vendors could provide virtual patches outside the database until organizations complete their DB patching cycle," Shulman says.

In Oracle's defense, the fact that customers take so long to deploy patches highlights the predicament the database developer is in when it comes to patching vulnerabilities that require architectural changes within its platforms. Many customers depend on Oracle to keep mission-critical data stores up at all times and when a patch breaks their databases, that's a huge problem for everyone involved. According to Markovich, Oracle has actually made improvements on that front.

"I think Oracle's patches are actually more streamlined. A year back or two years back they would force in a bunch of patches that were not really realated to security and it would break stuff and be hard to implement," Markovich says. Now it is purely security."

And in the same vein, the company bought database firewall vendor specifically to deal with unpatched vulnerabilities. But according to Securosis' Lane, it is wasting the opportunity to help customers on that front.

"We know that it is hard; Oracle bought Secerno to provide us an option of not having to patch, in other words to be able to create a database firewall tool to give us some relief in the meantime," he says. "But there has been very little going on from that front. We haven't heard about any new firewall rules being announced, we haven't heard about any updates to that product and platform and we haven't heard about any integration with any of the policy management sets. That's my complaint."

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-1421
Published: 2014-04-22
Cross-site scripting (XSS) vulnerability in Craig Knudsen WebCalendar before 1.2.5, 1.2.6, and other versions before 1.2.7 allows remote attackers to inject arbitrary web script or HTML via the Category Name field to category.php.

CVE-2013-2105
Published: 2014-04-22
The Show In Browser (show_in_browser) gem 0.0.3 for Ruby allows local users to inject arbitrary web script or HTML via a symlink attack on /tmp/browser.html.

CVE-2013-2187
Published: 2014-04-22
Cross-site scripting (XSS) vulnerability in Apache Archiva 1.2 through 1.2.2 and 1.3 before 1.3.8 allows remote attackers to inject arbitrary web script or HTML via unspecified parameters, related to the home page.

CVE-2013-4116
Published: 2014-04-22
lib/npm.js in Node Packaged Modules (npm) before 1.3.3 allows local users to overwrite arbitrary files via a symlink attack on temporary files with predictable names that are created when unpacking archives.

CVE-2013-4472
Published: 2014-04-22
The openTempFile function in goo/gfile.cc in Xpdf and Poppler 0.24.3 and earlier, when running on a system other than Unix, allows local users to overwrite arbitrary files via a symlink attack on temporary files with predictable names.

Best of the Web