Oracle objects to Reg security coverage

[InfoSec News <isn () c4i org>]

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 majordomo () attrition org with 'unsubscribe isn' in the BODY
of the mail.