http://www.theregister.co.uk/content/4/24289.html By Thomas C Greene in Washington Posted: 05/03/2002 at 09:24 GMT I received an e-mail memo from Oracle Security Product Management Director Mary Ann Davidson taking exception to my recent article, Staying on top of Oracle's holes. The text of Mrs Davidson's letter is reproduced below in full, and my reply is reproduced below that in full as well. Our exchange occurred on Friday, 1 March. I encourage readers to e-mail me with their take on this, with a mind to future publication. Have I been unfair to Oracle? ----------------------------------------------------------------------- Dear Mr. Greene: I am writing in response to your article http://www.theregister.co.uk/content/53/24244.html In your article, you say: "...we note that Oracle has been less than eager to disseminate useful information about these issues, most likely because they illustrate the essential fatuity of its 'unbreakable' ad campaign." We believe this to be factually incorrect. Oracle's policy is to addresses significant security vulnerabilities by issuing security alerts. Our policy is also to issue an alert only after the vulnerability has been patched on all affected releases and platforms and to post the alert on Metalink and Oracle Technical Network (OTN). In cases for which a vulnerability has already been made public on the Internet, we will post available patches immediately, and others as they become available. Due to the number of supported releases and operating systems (>20), we may need to produce a significant number of patches - as many as 78 for one vulnerability - so that all customers are protected. We are the only vendor who has such significant multi-release and multi-platform security patch issues. I believe David Litchfield has complimented us on several occasions on our attention to vulnerabilities and the speed with which we execute, given the number of patches we need to produce. You say: "According to Counterpane, the worst unresolved issue is the fact that the Oracle server will respond to external procedure calls, say from a custom application, with access to OS-level libraries and functions." This vulnerability was found by Oracle internally at about the same time David Litchfield found it and reported it to Oracle (we did give him credit, as per our standard security alert policy). Oracle is working on a permanent fix but has issued an Alert with a very robust workaround. We have not heard any complaints from customers or researchers (with whom we vetted the workaround prior to issuing the alert) about inadequacy in the workaround. We do make every attempt to fix security vulnerabilities as soon as possible, but some problems are harder than others to address, and harder to address in such a way that the fix is backwards-compatible. We also insist upon comprehensive testing to ensure that the fix works and does not destabilize the product. You say: "If you're running Oracle on a Windows system, the default installation is that Oracle runs in the system [root] environment, and that means that basically anyone who has access to the network functionality has the ability to run local applications and functions as an administrator," Counterpane's Tina Bird warned. Due to the Windows NT architecture, which does not allow you to do certain privileged operations unless you are SYSTEM, Oracle does need to run as SYSTEM on NT, which is not the case on UNIX operating systems. You say: "We'll note that a vulnerability in the PL/SQL DADs (Database Access Descriptors) can enable an attacker to escalate his privileges regardless of his initial status, so this is not an issue to be trifled with. " It's unclear what this refers to. We have fixed all known PL/SQL vulnerabilities (with patch information and/or workarounds, posted on Metalink and OTN) for both Oracle9i application server and Oracle9i database. We would expect Counterpane to bring any new issues they identify to Oracle, so that we may quickly address them, as is industry-standard practice for customers and security researchers. It would be unfair to criticize us for not responding to something that was never brought to our attention, and - we believe - irresponsible to make a new vulnerability known without giving us a chance to fix it. You say: "Thus it's necessary to test any Oracle patch thoroughly and meticulously before integrating it into a 'live' system." We make every effort to get patches into patch sets, as we run full regression tests on patch sets. For one-off patches (which we do primarily for security alerts in addition to putting them in patch sets where applicable), we make every effort to test the patch thoroughly, and often offer the patch to researchers to test themselves. We are keenly aware that our customers run mission-critical, 7x24 systems on Oracle, for which stability and reliability is paramount, and we test and release patches accordingly. A side benefit of patch sets is that we believe customers are more likely to apply patch sets than one-off patches (though we do both). As you know, the biggest issue with security patches is that they so often go unapplied, hence including security fixes in patch sets increases the chances that customers will apply the patch. You say: "The most readable and detailed document on workarounds doesn't come from Oracle, sadly, but is instead Litchfield's paper (linked below). No one administering an Oracle database can afford to ignore it. " This is indeed a very useful paper, and we are especially appreciative that David Litchfield gave it to us in advance of his presentation at Black Hat. (It is, however, more applicable to the Oracle9i Application Server.) We are looking at each element in the paper involving configuration as a candidate for a default configuration change, and in fact, many of the configuration issues David brought out are being changed in the earliest product release for which we can make the change. Part of a commitment to security is making the defaults appropriately secure, so administrators or others do not have to tweak a lot of parameters to achieve security: the product is secure "out-of-the-box." Our customers are among the most security-aware in the world; it is precisely because we market that we are secure that we take great pains to notify customers of security vulnerabilities when we - or others - find them. It's very simple; you do the right thing by customers. We run our own systems on Oracle, so the security golden rule of 'treating the customer as you would yourself' is especially applicable. It's easy to criticize vendors for security vulnerabilities, but the target is all too easy to hit. A better approach might be to look at a vendor's track record: we have spent millions on information assurance - having someone other than Oracle vet our security claims - through 14 independent security evaluations, far more than any other vendor. We have a secure product development process which we continuously strive to improve. Unlike many vendors, we do not blame the researcher for finding security issues in our products; rather, we give attribution to them, and make every effort to address the issue for all customers, on all releases, as quickly as possible, a feat particularly challenging for us given the number of product releases and operating systems we support. We use "vulnerability lessons learned" to continuously improve our development processes, our default installation and/or our documentation. Our long-standing commitment to secure product design, development and delivery and independent measures of assurance is what 'Unbreakable' is all about. Long after the marketing campaign is done, we will still be fanatical about providing the most secure mission-critical software in the business. Regards - Mary Ann Davidson -------------------------------------------------------------------------------- Mrs Davidson, "We would expect Counterpane to bring any new issues they identify to Oracle, so that we may quickly address them, as is industry-standard practice for customers and security researchers. It would be unfair to criticize us for not responding to something that was never brought to our attention, and - we believe - irresponsible to make a new vulnerability known without giving us a chance to fix it." This is not new. Quoting Litchfield: "By default it is possible to administer PL/SQL DADs remotely without needing to authenticate. This is obviously not a good thing. Whilst this doesn't allow an attacker an opportunity to run commands they could attempt to change the user ID and password used to connect to the database server trying to boost privileges by using a default user login and password such as SYS, SYSTEM or CTXSYS." I am not aware of a patch for this, but in the article I recommend the Oracle workaround: "To remove the potential vulnerability identified in c), change the AdminPath entry located in $ORACLE_HOME$\Apache\modplsql\cfg\wdbsvr.app to an independent path name that does not reveal the exact location of the true administration pages." Litchfield doesn't specify how high a malicious user might escalate his privileges, but since we don't know it's not to System, one is better off assuming the worst. This strikes me as an additional piece of ammunition in attempting to exploit the (as yet unpatched) external procedure call vulnerability. Correct me if I am wrong. "It's easy to criticize vendors for security vulnerabilities, but the target is all too easy to hit." I don't recall criticizing Oracle for having vulnerabilities per se. But calling one's product "unbreakable" -- well, a claim like that is an invitation to public ridicule. Indeed, I think I've been fairly restrained by Register standards. "As you know, the biggest issue with security patches is that they so often go unapplied, hence including security fixes in patch sets increases the chances that customers will apply the patch." I agree; but this is no reason not to test them before using them in critical systems. I'm simply offering my readers the best advice I can. It is not an indictment of Oracle's QC practices, and certainly shouldn't be taken that way. It's also not meant to discourage patching, but rather to encourage caution. What's wrong with that? "We believe this to be factually incorrect. Oracle's policy is to addresses significant security vulnerabilities by issuing security alerts." What about people running older, unsupported kit? Do they get these alerts? Can they log on to the site and download patches? Not all users are customers. Good vulnerability disclosure is not simply a matter of notifying one's current active customers. I would expect your department to keep the tech press informed, to put the word out to those outside your normal channels of disclosure and support. I have not seen enough effort from Oracle to publicize the issues broadly. Considering the popularity of your products and the severity of some of these vulnerabilities, it's my opinion that the company should be shouting from the rooftops about this. Oracle users are playing 'beat the clock' with the blackhat development community right now. They need information if they're going to win. IMHO Oracle can and should do a better job of disseminating that information widely. Regards, Thomas - ISN is currently hosted by Attrition.org To unsubscribe email majordomoat_private with 'unsubscribe isn' in the BODY of the mail.
This archive was generated by hypermail 2b30 : Wed Mar 06 2002 - 03:06:42 PST