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."