eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Brace yourself: Another quarterly CPU (Critical Patch Update) is due out from Oracle Corp. on Jan. 17.
With it will come what customers refer to as a nightmare of testing to ensure that the patch set doesnt break anything. If history is any guide, the event will soon be followed by headlines that scream about unpatched vulnerabilities left open for months upon months, and/or security researchers will point to Oracle patches that dont properly install fixed files or dont fix what they were supposed to.
Enterprises are split regarding whom theyd like to draw and quarter: the security researchers who reveal unpatched vulnerabilities, or Oracle for sitting on vulnerabilities so long. But one thing is clear: Going forward, a more balanced look at Oracles security handling will begin to emerge.
Thats because, on Wednesday, Oracle took the first step toward abandoning its no-comment policy on security issues, opening its security processes up to a daylong probing by the media, with eWEEK being the first guinea pig in the experiment. This could be big for IT people in the trenches: It could herald the end of C-level executives squeaking in alarm over headlines that database administrators tend to disregard because they believe their Oracle technology isnt at great risk.
The history of how Oracle has approached security is a long one, but when it comes to talking about security problems, the company says it has always put its customers needs first—hence the no-comment policy.
Why Oracle changed its mind is a long story. But the straw that broke the camels back came in November. It came in the form of a report from security research Alexander Kornbrust, of Red-Database-Security GmbH, which stated that Kornbrust had found some 252 unpatched holes in Oracle Database 10g.
Thats a lot of holes. And it made a lot of Oracles customers jump on the phone.
Oracle told customers that an initial analysis of Kornbrusts findings determined that the majority—164—were false positives. Oracle Senior Management of Software Development Mark Fallon told eWEEK the actual number of real flaws was “a lot lower,” and an Oracle spokeswoman said she believed it was on the order of about 10.
The company said that the high number of false positives are due to the fact that Kornbrust used a simple search rather than a data flow analysis.
Indeed, Kornbrust used a simple text editor to find the SQL injection bugs in 4 hours in a hotel room in Sweden, he told eWEEK. Hes not embarrassed by the unsophisticated tool, though, given that even one exploit would be a worthwhile find.
“Keep in mind that a hacker only needs one working exploit (zero day), not dozens or hundreds,” he said in an e-mail exchange. Within those 4 hours, he wrote three working exploits that allow privilege escalation, he said.
As for using data flow analysis, Kornbrust said thats out of range for a small outfit like his. “I know that a proper data analysis takes a lot of time and eliminates the false positives,” he wrote. “Oracle has a lot more resources than Red-Database-Security, and Im doing this in my free time, and Im quite busy at the moment.”
Next Page: Devoting resources to research vulnerabilities.
Page 2
Oracle does have a lot of resources, but vetting 252 reported vulnerabilities isnt where its people want to devote them. As it is, the automated code assessment tools Oracle uses tend to turn up false positives, John Heimann, director of Oracles security program management, told eWEEK.
“These tools can help you find potential issues,” he said. “But not everything found by the tools is necessarily a security bug. … Automated tools arent necessarily a substitute for human thought.”
And in the hands of Oracle customers, such tools can result in a stack of vulnerabilities, plunked down in front of Oracle reps, who then have to pore through them and explain away false positives.
Thomas Kristensen, chief technology officer for the bug-monitoring company Secunia, is recognized as an impartial voice who has to deal with both vendors and security researchers. But he comes down on the side of Kornbrust when it comes to who should devote their resources to research vulnerabilities.
“One can always argue that its the security researcher that should do all the work of verifying and assessing vulnerability of flaws found,” he said. “But you can also say its the vendors job to find out if its as dangerous as [the researcher] thinks. … Its difficult to assess who should do what. But in the end, the one receiving money from the customer is the vendor. You can say researchers are doing a lot of work on behalf of the vendor for its customers.”
Still, Kristensen said, its important for researchers to at least prove the concept to a certain point, to explain to the vendor what the issues are and to explain criticality to some extent. “But the full extent of the vulnerability, you cant expect security researchers to go in and do all the work to do that,” he said. “Its the vendors responsibility to do that.”
More on companies minds, however, are two things: the time between flaw discovery and patch issuance, and patch quality.
Oracle claimed that virtually all the issues Kornbrust discovered have already been fixed in the latest Oracle database release, 10gR2. It also said that fixes for all legitimate vulnerabilities affecting older versions will be released to customers in CPUs.
The problem with that, Kornbrust said, is that many bugs are still unfixed in 10gR1. Thats backward priorities, he said, given that most customers havent yet upgraded to R2. “At the moment, most 10g customers are using R1 as a production database and not R2,” he said. “There is no advantage for most customers that the bugs are already fixed in a newer, not used version.”
One blogger on Information Security News Desk—run by members of the security community—put it this way: “[Oracle Chief Security Officer Mary Ann Davidson is] right that fixes to even simple vulnerabilities still have to go through a full test and release cycle, but shes being disingenuous in claiming that Oracle has been responding in a timely manner to the notifications theyve received. They havent (and this is not new behavior).”
Next Page: A lot of code to test.
Page 3
The fact of the matter, though, is that Oracle has five product stacks, with all major platforms. Thats a lot—between 30 million to 40 million lines—of code to test, cross-product. Oracle doesnt want to ship patches that will break production databases. Hence, the lengthy gaps.
Given the number of products Oracle has acquired on the buying spree that started with PeopleSoft and most recently encompassed Siebel, its hard to imagine it will succeed in cutting the time between flaw discovery and patch release. And what will Project Fusion do to the code set? Its meant to be a brand-new rearchitecting of the way Oracles applications work, new from the ground up, using the best of the Siebel, PeopleSoft, Oracle, J.D. Edwards and all the smaller acquisitions products.
Dan Downing, vice president of testing services at business applications testing, hosting and managing company Mentora, said that could have good and bad points. “On one hand, thats a wonderful thing, because it will mean Oracle doesnt have to patch up old sins,” he said. “Software architectures get leaky after awhile.
“But from a practical perspective, it means entering a whole new evolutionary cycle of a chunk of software that initially will be immature, and there will be lots of problems with it before it matures.”
But given the feedback from customers on this issue, Oracle is still dead set on improving both patch turnaround time and patch quality, according to Darius Wiles, senior manager of Oracle Security Alerts.
“Obviously its something that concerns us and something we plan to improve,” he said. “[But] if a customer cant apply a patch, they wont phone the press, but its their No. 1 concern. They want to make sure the patch will work the first time. If you ask them, theyll say their No. 1 complaint is to improve the quality of patches.”
But patch quality makes for extended testing time, meaning that it makes it still tougher to shorten the time to patch delivery. “Obviously we want to have our cake and eat it too,” Wiles said. “Were looking at internal processes. For nonsecurity bug processing, we want to streamline that and get owners assigned to [issues] more quickly, and make sure developers [assigned] to do fixes find out about it as quickly as possible, and make sure resources are available to do that fix.”
So where does all this leave customers as they brace for the coming CPU and the coming headlines? With this knowledge: The number of vulnerabilities security researchers report and that end up in headlines is largely composed of false positives, so dont take the number to heart. Do bear in mind that there will be a kernel of truth—i.e., true positives—at the heart of security researchers reports.
After all, Oracle isnt alone in dealing with a massive code set that has flaws. Any massive code set does.
But going by a day spent at Oracle headquarters, the takeaway is that Oracle is taking customers complaints to heart: Its taking the positives seriously, is battling to reduce the time to patch delivery and is trying to do so while improving patch quality.
And its doing all this not because of security researchers and negative headlines, but because of customer feedback. So for those customers who are providing that feedback, keep it up. For those who arent, it wouldnt hurt to start.
Check out eWEEK.coms for the latest database news, reviews and analysis.