| QUESTION & ANSWER |
Oracle owns up to patching problems |
 |
By Bill Brenner, Senior News Writer
17 Jul 2006 | SearchSecurity.com |
|
|
Oracle says many platforms and mountains of source code have forced some patching missteps, but the database giant argues that its program is not as bad as critics suggest.
This article originally appeared on SearchSecurity.com. Security researchers like David Litchfield [managing director at UK-based Next Generation Security Software Ltd.] regularly criticize Oracle for releasing quarterly CPUs that don't fully fix flaws. Are these criticisms justified or are they off base?
Darius Wiles: Some of the problems have been exaggerated, but there have been times when a vulnerability we thought was fixed turned out not to be. Things are sometimes missed in the testing and development process. A fix might look fine to us, but then certain issues come into play in the customer environment that we don't see. We are also dealing with roughly 150 platforms, and sometimes the problem is that a fix works for most platforms but not all of them.
John Heimann: It's a challenge when there are so many platforms to support. We're working to thin it out. We're also working with very complex code -- more complex than the space shuttle. There's more of an art to this than a science.
What are some of the specific steps being taken to bring more order and consistency to the process?
Wiles: We're working to have a test process that more closely mirrors the customer environment. We're also moving toward using technology from Fortify Software to further automate the process of analyzing our source code for vulnerabilities. We're really pinning our hopes on Fortify to help us correct inconsistencies in patching among different platforms.
Heinmann: We've also focused a lot on standards, training and compliance to ensure stronger security from the very beginning of the code-writing process. We've focused hard on making people more aware of security as they do their day-to-day jobs. We're working to really drill this into the heads of the developers.
Wiles: On some of our teams, we've had people trying to hack each other's products to find weaknesses.
A lot of this seems to be geared toward hardening security in newer products and researchers have praised you for that, but they feel like customers who use older supported Oracle products are being left in the lurch. What's your response?
Wiles: There's a bug-fix lifecycle we follow and day to day, developers are working with the mainline code -- the code put into our new releases -- which is constantly improved. When there's a bug, we fix it in the mainline code first. It's the quickest and most efficient way to address flaws in the older products and then those fixes are automatically worked into our newer products. We didn't want to invent a whole new process just to deal with older bugs. CPUs are meant to address the highest-priority issues and fixes may come more slowly to customers with older versions.
In the April CPU, certain issues were patched while others were delayed. How do you determine when it's appropriate to issue a partial fix?
Wiles: Calling it a partial fix isn't really accurate. Our goal is to patch everything on the [CPU] release dates, which we announce a year in advance. We're committed to following the schedule, [but] we often have patches that lag the release date.
Heinmann: Our objective is to have all fixes for all platforms on day one. When we can't, we prioritize.
Wiles: When there's a patch that still needs fixing, we have to weigh the customers' needs. If the CPU comes out and a certain fix isn't ready for all platforms, we release what's ready. And for customers using a product for which a patch isn't ready, we can at least let them know that something is coming in three weeks so they can plan for it.
Do you think there would be less criticism about these things if the CPU documentation was easier to follow? Several experts and DBAs have said the documentation is confusing and that there's never much detail describing what the specific vulnerabilities are.
Wiles: The CPU scheme has been improved and is still being improved. We have ongoing discussions about how many details to disclose. The goal is to offer details, but not so many that it can be harmful. Adding more detail to future advisories is something that's on the table. One challenge is that we're trying to reach out to different audiences with these advisories -- DBAs and less technically oriented people like CSOs who need to determine how much risk a flaw poses to their organization. There can be some conflict between the more technical people and what they want and the less technical crowd.
We could do a better job of walking people through the advisories, but my concern is that putting more words into the advisory would make it an inch thick.
Do you ever see Oracle adopting a bulletin style like Microsoft's, in which there are clear details on each flaw is and how it could be exploited?
Heinmann: I can never see us moving to an advisory like Microsoft's. I give Microsoft a lot of credit for its security improvements. But our objective is to give people enough information to assess and address their risks, not to entertain them. It also takes a lot more time and planning to install an Oracle patch, so releasing more detail could expose customers to more risk.
You suggested that some of the problems vulnerability researchers publicize are exaggerated. What do you mean by that?
Wiles: The communications we have with the hacking community are actually extremely good. [David] Litchfield has been very helpful in the past. But some of what the researchers report to the press gets overly hyped. There's one-upmanship that takes place in the larger hacker community. One time, someone reported 12 security issues and another person reported the same thing as one issue. For researchers looking for publicity, every flaw is critical.
One of the criticisms leveled at Oracle is that it sits on flaws that are more than a year old. Alexander Kornbrust [database security researcher and business director at German firm Red-Database-Security GmbH], for example, keeps a running tab of open Oracle security holes on his Web site and the latest count is 45. The oldest flaw was first disclosed in 2003 and many were first reported last year, he told us recently. Is this part of the hype? If not, is it reasonable to expect customers to live with open vulnerabilities for that long?
Wiles: First, there are reasons we don't fix everything immediately. There's a prioritization we have to follow. And one thing we do is try to make distinctions. There are certain flaws that aren't really security bugs. Some of them are configuration problems. So a product can be secure overall, but an underlying problem may exist that could allow someone to access something. Sometimes there's an issue that the user can fix on their own. When that's the case, we give them details on how to do it.
|
|
|
|
