Opinion: Unshipped patches, unpatched holes, calls for resignations: Why don't Oracle execs and security researchers settle their differences?The recent Oracle security "news" is about as new as my 1995 truck. No, forget the truck—this stuff is as "new" as the dirt in my trucks phenomenally filthy bed. To wit:
Item: Oracle didnt ship the full April CPU.
Item: Oracles update didnt plug a hole or multiple holes.
Item: Security researcher David Litchfield continues to call for Oracle Chief Security Officer Mary Ann Davidson to resign or be fired.
Item: Oracle refuses to comment.
Item: Davidson says security researchers should shut up. Oh, wait, she didnt say that this time—it was in the summer. Or was it about the January CPU? Its all blurring together.
What is this, Groundhog Day? Do we have to have the same headlines every four months, like clockwork? Could we just get Davidson into a ring with the security researchers, throw in some Jell-O and let them wrestle each other into submission?
eWEEK security reporter Ryan Naraine suggested the Jell-O match, and I obliged by suggesting the idea to Oracle and to Litchfield, who countered by saying it would make a better tag team if it included Oracle security researchers Alexander Kornbrust and Cesar Cerrudo—all of whom have taken Oracle to task over patch quality and length of time taken to fix holes.
Of course, the Jell-O suggestion is tongue-in-cheek, but the premise is sound: We must get these security researchers and Oracles security team together in a constructive way, or enterprises will never get to the bottom of the sensational headlines, will never be able to figure out which holes to take seriously, will continue hounding Oracle with worry over false positives, and will continue to be left hanging as they wait for updates to clear Oracles lengthy testing cycle.
I had come away believing that Oracle was working hard on both patch quality and shortening fix turnaround time after spending a day around a table with Oracles security team in January.
At that time, Darius Wiles, senior manager of Oracle Security Alerts, told me that Oracle is dead set on improving both patch turnaround time and patch quality.
"Obviously its something that concerns us and something we plan to improve," he told me. "[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."
Improving patch quality means extended testing time, meaning that focusing on quality makes it tougher to shorten patch delivery times.
"Obviously we want to have our cake and eat it too," Wiles told me. "Were looking at internal processes. For non-security 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."
Thats what Oracle said in January. Where is it now regarding reducing patch time and improving patch quality, five months later? Unfortunately, after opening up for a refreshingly candid look at its security workings, the company has once again returned to the security cone of silence.
Security experts call Oracles patching process slipshod and ponder whether the company needs a Microsoft-style security makeover. Click here to read more.
Outside security researchers, on the other hand, are only too happy to point out what Oracle needs to do to achieve these two goals. Heres what Litchfield—who has been squabbling with Oracle over these issues for some time—had to contribute to this one-sided conversation.
In an e-mail exchange, he said that in terms of philosophy,
1) Oracle should admit it has a problem.
2) Oracle should stop playing the blame game and stop trying to discredit researchers in an effort to shift the focus away from its security problems. The researchers goals and Oracles are the same—a more secure product—and Oracle should recognize this.
3) Oracle hides behind its 14 independent security evaluations [which Litchfield is currently researching]. For the Common Criteria evaluations it turns out that Oracle wrote the criteria (here in PDF form) against which it was to be measured—how could it not be accredited under such conditions? Also, to quote the to quote the evaluation reports, "certification is not a guarantee of freedom from security vulnerabilities" and "the issue of a Certification Report is not an endorsement of a product"—so Oracle should stop waving the reports as if they were endorsements and that the reports are "proof" that its secure.
In terms of practical recommendations, Litchfield said,
1) Oracle should spend more money on quality assurance of patches and of products before they ship.
2) Oracle should expend more effort on securing extant code in preference to writing new code.
3) Oracle should rework its security tools. Researchers have proven that Oracles code-scanning tools have failed to a large extent—now Oracle should work out why and change the tools accordingly.
Regardng management, Litchfield said,
1) Mary Ann Davidson should resign or be fired. "She alienates the one group of people that are actually in a good position to help her—security researchers that understand Oracle product. Using me as an example—she once wrote a perspective piece [in which she] accuses me of implicit threats: Some [researchers] engage in ... implicit threats ("Fix it in the next three weeks because I am giving a paper at Black Hat"). As I often request this and was the only one speaking at Black Hat at the time, this is a clear reference to me.
2) "What Mary needs to understand is that it is just common courtesy to ask—I dont need to ask at all. I could go right ahead a drop them in it from a great height—but rather than do that I inform them of my intentions—and whats more, if the patches arent ready, Ill change my talk. I have 68 security flaws waiting to be fixed—most of them critical. If I really was the person Mary paints me out to be, then, rather than informing Oracle, Id just release zero-day exploit code. The more Mary attacks, the more the more you just throw your hands up in the air in disgust but you grit your teeth and get on with it—because Im _not_ the person she claims me to be."
Litchfield said he believes that Davidsons track record in the job has been "poor."
"What she says publicly doesnt marry up to whats happening in her software," he said. "This means either that she is lying or that shes telling the truth but no one in Oracle is listening to her. Either way this makes her position untenable. We were told that 10g Release 2 would be secure—indeed Oracle guaranteed me that Id not find any flaws in it. Since then Ive sent in plenty—most of them critical."
Lets be clear on this: Admins, those in the trenches, dont pay much mind to any of this stuff. Theyre fairly uniform in considering their Oracle databases to be locked down. The people who care are the execs who read the headlines and arent sure what to believe. Theyre the ones who generate calls to Oracle, and theyre the ones who pester their admins to find out whats being done about the gaping database holes.
Would a sit-down between researchers such as Litchfield and Oracle make sense? Yes, but Litchfield said he believes Davidson wouldnt go for it. Past sit-downs have been, shall we say, unproductive, Litchfield said.
Stop. Just stop. Oracle, security researchers, we know youre all working hard to make sure that products are locked down. Just please, get the communication thing worked out.
Do it soon, or were ordering the Jell-O.
Lisa Vaas is Ziff Davis Internets news editor in charge of operations. She is also the editor of eWEEK.coms Database and Business Intelligence topic center. She has been with eWEEK and eWEEK.com since 1995, most recently covering enterprise applications and database technology. She can be reached at lisa_vaas@ziffdavis.com.
Check out eWEEK.coms for the latest database news, reviews and analysis.
