Opinion: Complete failure of Oracle security response and utter neglect of their responsibility to their customers
David Litchfield
Many of my customers run Oracle. Much of the U.K. Critical National
Infrastructure relies on Oracle; indeed this is true for many other
countries as well. I know that there's a lot of private information about me
stored in Oracle databases out there. I have good reason, like most of us,
to be concerned about Oracle security; I want Oracle to be secure because,
in a very real way, it helps maintain my own personal security. As such, I
am writing this open letter
Extract from interview between Mary Ann Davidson and IDG
http://www.infoworld.com/article/05/05/24/HNoraclesecurityhed_1.html
IDGNS: "What other advice do you have for customers on security?"
Davidson: "Push your vendor to tell you how they build their software and
ask them if they train people on secure coding practices. "
Now some context has been put in place I can continue.
On the 31st of August 2004, Oracle released a security update (Alert 68
[http://www.oracle.com/technology/deploy/security/pdf/2004alert68.pdf]) to
address a large number of major security flaws in their database server
product. The patches had been a long time in coming
[http://www.eweek.com/article2/0,1759,1637213,00.asp] and we fully expected
that these patches would actually fix the problems but, unfortunately this
is not the case. To date, these flaws are still not fixed and are still
fully exploitable. I reported this to Oracle a long time ago.
The real problem with this is not that the flaws Alert 68 supposedly fixed
are still exploitable, but rather the approach Oracle took in attempting to
fix these issues. One would expect that, given the length of time they took
to deliver, these security "fixes" would be well considered and robust;
fixes that actually resolve the security holes. The truth of the matter
though is that this is not the case.
Some of Oracle's "fixes" simply attempt to stop the example exploits I sent
them for reprodcution purposes. In other words the actual flaw was not
addressed and with a slight modification to the exploit it works again. This
shows a slapdash approach with no real consideration for fixing the actual
problem itself.
As an example of this, Alert 68 attempts to fix some security holes in some
triggers; the flaws could allow a low privileged user to gain SYS privileges
- in other words gain full control of the database server. The example
exploit I sent to Oracle contained a space in it. Oracle's fix was to ignore
the user's request if the input had a space. What Oracle somehow failed to
see or grasp was that no space is needed in the exploit. This fix suggests
no more than a few minutes of thought was given to the matter. Why did it
take 8 months for this? Further, how on earth did this get through QA? More,
why are we still waiting for a proper fix for this?
Here is another class of thoughtless "fix" implemented by Oracle in Alert
68. Some Oracle PL/SQL procedures take an arbitrary SQL statement as a
parameter which is then executed. This can present a security risk. Rather
than securing these procedures properly Oracle chose a security through
obscurity mechanism. To be able to send the SQL query and have it executed
one needs to know a passphrase. This passphrase is hardcoded in the
procedure and can be extracted with ease. So all an attacker needs to do now
is send the passphrase and their arbitrary SQL will still be executed.
In other cases Oracle have simply dropped the old procedures and added new
ones - with the same vulnerable code!
I ask again, why does it take two years to write fixes like this? Perhaps
the fixes take this long because Oracle pore through their code looking for
similar flaws? Does the evidence bear this out. No - it doesn't. In those
cases where a flaw was fixed properly, we find the same flaw a few lines
further down in the code. The DRILOAD package "fixed" in Alert 68 is an
example of this; and this is not an isolated case. This is systemic. Code
for objects in the SYS, MDSYS, CTXSYS and WKSYS schemas all have flaws
within close range of "fixed" problems. These should have been spotted and
fixed at the time.
I reported these broken fixes to Oracle in February 2005. It is now October
2005 and there is still no word of when the "real" fixes are going to be
delivered. In all of this time Oracle database servers have been easy to
crack - a fact Oracle are surely aware of.
What about the patches since Alert 68 - the quarterly Critical Patch
Updates? Unfortunately it is the same story. Bugs that should have been
spotted left in the code, brand new bugs being introduced and old ones
reappearing.
This is simply NOT GOOD ENOUGH. As I stated at the beginning of this letter,
I'm concerned about Oracle security because it impinges upon me and my own
personal security.
What is apparent is that Oracle has no decent bug discovery/fix/response
process; no QA, no understanding of the threats; no proactive program of
finding and fixing flaws. Is anyone in control over at Oracle HQ?
A good CSO needs to more than just a mouthpiece. They need to be able to
deliver and execute an effective security strategy that actually deals with
problems rather than sweeping them under the carpet or waste time by blaming
others for their own failings. Oracle's CSO has had five years to make
improvements to the security of their products and their security response
but in this time I have seen none. It is my belief that the CSO has
categorically failed. Oracle security has stagnated under her leadership and
it's time for change.
I urge Oracle customers to get on the phone, send a email, demand a better
security response; demand to see an improvement in quality. It's important
that Oracle get it right. Our national security depends on it; our companies
depend on it; and we all, as individuals depend on it.
Cheers,
David Litchfield
David Litchfield
I know you this wasn't your intent when you wrote it, but:
> That means 70 000 000 € spend by Larry for the silly Yacht - you, David,
> could charge 100 000 per day and still deliver more value.
I just want to make it clear that all I'm looking for from Oracle is, not a
job to review their code, but to treat security properly and give their
customers the respect they paid for.
Cheers,
David
Cesar
comments (I can't avoid doing this :)):
I remember reading an article where Larry Ellison said
that Oracle database
server were used by FBI, CIA, USSR goverment, etc. he
referenced that as
saying our software is the most secure, top goverment
agencies from the most
powerful nations use it. If you hear or read that it
sounds great and if you
were looking for a database server at that moment
maybe you would run to buy
Oracle software, the same when you hear and read
Oracle Unbreakable
everywhere. What Larry Ellison says it is very easy to
say but it is also
very difficult to prove. It seems that this kind of
statements have been
useful for Oracle since the company continues doing
the same, "just
talking".
I can say that we at Argeniss break Oracle database
server all the time, we
are tired of breaking Oracle, it's so easy, Oracle
software is full of
security vulnerabilities and this is nothing new, most
security researchers
know about this and also the bad guys who are actively
exploiting the
vulnerabilities. But I can say this and I can also
prove it, we have found
more than a hundred vulnerabilities and we can show
them to people. I wonder
if Larry Ellison can prove all the statements he says
or Oracle people say.
What I have seen is Oracle doesn't care much about
security, it's just a PR
issue for Oracle. When you report a vulnerability to
Oracle you get an
answer saying we will take a look at this, then months
or sometimes years
after the initial vulnerability report they release
(or not) a patch , that
sometimes doesn't work, but what is amazing is that
they just fix the bugs
you reported they don't audit similar bugs to fix all
at once, I can't
understand this, we are working for free for them and
they are not doing any
effort.
Basically when Oracle security problems arise, Mary
Ann Davison and Oracle
PR team try to deviate attention and blame anyone
without focusing on the
real problem: "Oracle insecurity". Oracle security has
not improved over the
last years, everytime there are more and more holes,
also security patches
are having holes, QA seems that it is not being done
at all!. But everytime
you hear Oracle people, they will say "Oracle
Unbreakable", "An oracle d/b
has not been broken into in 15 years...", "We have 14
security
certifications", "Security researchers are evil",
"some people complain
it's too secure - literally cannot break into it..."
etc. but you never will
hear and also see something like: "We are working hard
on improving security
because we are doing this and this", "We are fixing
all the bugs", "We want
to work with security resarchers", "We stopped
development to fix the
security bugs"... etc.
I think that Oracle will start to suffer more and more
because security
problems, Oracle reminds me Microsoft some years ago,
when MS had a lot of
security issues that were reflected on sales, until
Oracle doesn't see side
effect on sales or customers start to pressure,
everything will be the same.
I'm seriously thinking to release some Oracle remote
0day next time I hear Larry o Mary saying bullshit to
shut their mouths.
Related info:
http://www.crn.com/sections/security/security.jhtml?articleId=171000880
http://www.eweek.com/article2/0,1895,1860184,00.asp
http://www.argeniss.com/research/SQL-Oracle.zip
http://www.argeniss.com/research/CWM2_OLAP_AW_AWUTILVuln.txt
Regards.
Cesar Cerrudo.
CEO & Founder.
Argeniss - Information Security
http://www.argeniss.com
______________________________________________________
Yahoo! for Good
Donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/
David Litchfield
> With all due respect to your wishes and intent, a research on different
> vendors, showing what vendor responds to threats, after how long and how
> effectively plus how many security issues appear with each would have made
> sense to me.
Having worked closely with the security teams of most large commercial
vendors (IBM, Oracle, Microsoft, Apple, HP, Adobe, Real) I can quite
honestly say that, of all of them, Oracle is the only company to still treat
security in this way. Most other organizations "got it" years ago and while
there could be improvements made in various areas the most improvement could
be made at Oracle.
> Showing the Good and thus flushing the Bad without dissing anyone. Pure
> facts.
Firstly, it's due to the facts that I posted as I did. It is fact that the
patch for Alert 68 fails to properly fix a large number of holes it was
touted to fix. It is fact that a large number of companies that spent a
great deal of money installing the patch have wasted their time. It is fact
that Oracle database servers are still vulnerable to security holes that
were reported to Oracle years ago.
> Attacking one vendor may make sense in some cases.. yes, again, attacking
> one vendor in public in *this* *fashion* may be long over-due, but it also
> seems to me to be rather.. in poor taste? Especially coming out of the
> blue with no past public statements.
Oh, this wasn't out of the blue; and there have been a great number of
public statements about Oracle's failings. Not just from myself, I'll add,
but others as well.
>
> I sympathize with your concerns and I am known to be FAR from a person who
> doesn't voice his opinions - and loudly, but it only makes me wonder why
> now,
Because enough is enough.
> why them
Because they seem to be the only ones that don't get it.
> and why here.
I tried my local newspaper but they weren't interested. Bugtraq was my
second choice ;)
Seriously though, where else would you post this? Wasn't this one of the
main reasons for bugtraq being created in the first place?
>
> Now, I am not an Oracle advocate - far from it, but your subject line says
> it all, and makes me look-down on your post automatically, which is a
> shame:
> "Complete failure of Oracle security response and utter neglect of their
> responsibility to their customers"
>
> Complete? Failure? Utter neglect?
Yes. Based upon the facts the Oracle security response has been a failure.
How else can you describe it?
If you gave me a patch and said it fixed a security flaw and it turns out it
didn't I'd call that a failure. Multiply that by a factor of tens and you've
got yourself a complete failure. If I did this to my customers I'd sack
myself for neglect. Really, I would.
Cheers,
David
David Litchfield
>> Having worked closely with the security teams of most large commercial
>> vendors (IBM, Oracle, Microsoft, Apple, HP, Adobe, Real) I can quite
>> honestly say that, of all of them, Oracle is the only company to still
>> treat security in this way. Most other organizations "got it" years ago
>> and while there could be improvements made in various areas the most
>> improvement could be made at Oracle.
>
> Not many of them "got it". Some are simply worse.
This is not my experience. Certainly for all the bugs I have found the
patches released by all vendors save Oracle have fixed the problem. You call
me out on "where's my evidence?" I ask the same of you - where's your
evidence that this is not the case and that there are other big vendors that
are worse?
>> Firstly, it's due to the facts that I posted as I did. It is fact that
>> the patch for Alert 68 fails to properly fix a large number of holes it
>> was touted to fix. It is fact that a large number of companies that spent
>> a great deal of money installing the patch have wasted their time. It is
>> fact that Oracle database servers are still vulnerable to security holes
>> that were reported to Oracle years ago.
>
> Amazing statistics. Where are statistics on others?
What are you looking for stats on? Failed fixes? Time of bug report to time
of patch? It might actually make an interesting read. I'll put something
like this together over the coming few days and post my findings. In the
meantime, please accept my assurances that Oracle is on the bottom.
>> Because enough is enough.
>
> For security people maybe.. using Oracle for most business is a Business
> concern.
Whilst you are of course right that for most people Oracle is a business
concern what we also have to remember is that business is _all_ about risk
and managing that risk. Do I risk investing in a new product line? What's
the cost; what's the potential gain? What if it goes wrong? Adding more
risk, due to insecure software, is best avoided; especially with software
that's responsible for protecting the organization's crown jewels.
>>
>> Because they seem to be the only ones that don't get it.
>
> This is the place where you lost me, I am sorry. The only ones?
>
In my experience, yes. If you've got something to the contrary then please
share.
>
> It's not that I disagree with their behavior being questionable, I
> honestly believe a survey of how all vendors do where the s**t floats to
> the top without singling out the Bad but rather the Good, would work
> better.
I'll definitely put together the stats.
>
> This kind of attack may be "called for" but definitely will make Oracle
> less than willing to ever work with *you* or trust the community,
Sorry - but wasn't this one of the main reasons there was such a thing as
disclosure? As a means to get the vendors to treat security properly? Btw,
Oracle don't and never had trusted the "community" in the first place.
> plus it will immediately become a PR issue where they may chose to go on
> lawyer-PR strategies rather than "how do we make sure this never happens
> again by getting off that list".
> It simply looks like a rant, which is a shame.
On some levels it was a rant. Does that devalue the information? Not in my
opinion.
>
> Regardless, like I said, you better have a good plan on protecting
> yourself from liability. Right now, right or wrong, it appears like a
> personal attack from you. So, even if the entire community is behind you,
> most of the community won't help foot the legal bill.
I stand by my comments. They are based on fact. And, if it ever comes to it,
I would never want the "community" to help foot any legal bill.
Cheers,
David
Ivan .
On Security, Is Oracle the Next Microsoft?
http://www.eweek.com/article2/0,1895,1860184,00.asp
**********************snip**************************
Davidson has also taken a public stand against researchers like
Litchfield and Kornbrust, who she says exaggerate the dimensions of
security problems to get attention and expose innocent customers to
unnecessary danger by revealing product holes.
"Good news doesn't sell," Davidson said, in response to a question
about Litchfield's criticism of the OPatch utility.
**********************snip**************************
cheers
Ivan
On 1/7/05, David Litchfield <dav...@ngssoftware.com> wrote:
> Dear security community and Oracle users,
> Many of my customers run Oracle. Much of the U.K. Critical National
> Infrastructure relies on Oracle; indeed this is true for many other
> countries as well. I know that there's a lot of private information about=
me
> stored in Oracle databases out there. I have good reason, like most of us=
,
> to be concerned about Oracle security; I want Oracle to be secure because=
,
> in a very real way, it helps maintain my own personal security. As such, =
I
> am writing this open letter
>
> Extract from interview between Mary Ann Davidson and IDG
> http://www.infoworld.com/article/05/05/24/HNoraclesecurityhed_1.html
>
> IDGNS: "What other advice do you have for customers on security?"
>
> Davidson: "Push your vendor to tell you how they build their software and
> ask them if they train people on secure coding practices. "
>
> Now some context has been put in place I can continue.
>
> On the 31st of August 2004, Oracle released a security update (Alert 68
> [http://www.oracle.com/technology/deploy/security/pdf/2004alert68.pdf]) t=
o
> address a large number of major security flaws in their database server
> product. The patches had been a long time in coming
> [http://www.eweek.com/article2/0,1759,1637213,00.asp] and we fully expect=
ed
> that these patches would actually fix the problems but, unfortunately thi=
s
> is not the case. To date, these flaws are still not fixed and are still
> fully exploitable. I reported this to Oracle a long time ago.
>
> The real problem with this is not that the flaws Alert 68 supposedly fixe=
d
> are still exploitable, but rather the approach Oracle took in attempting =
to
> fix these issues. One would expect that, given the length of time they to=
ok
> to deliver, these security "fixes" would be well considered and robust;
> fixes that actually resolve the security holes. The truth of the matter
> though is that this is not the case.
>
> Some of Oracle's "fixes" simply attempt to stop the example exploits I se=
nt
> them for reprodcution purposes. In other words the actual flaw was not
> addressed and with a slight modification to the exploit it works again. T=
his
> shows a slapdash approach with no real consideration for fixing the actua=
l
> problem itself.
>
> As an example of this, Alert 68 attempts to fix some security holes in so=
me
> triggers; the flaws could allow a low privileged user to gain SYS privile=
ges
> - in other words gain full control of the database server. The example
> exploit I sent to Oracle contained a space in it. Oracle's fix was to ign=
ore
> the user's request if the input had a space. What Oracle somehow failed t=
o
> see or grasp was that no space is needed in the exploit. This fix suggest=
s
> no more than a few minutes of thought was given to the matter. Why did it
> take 8 months for this? Further, how on earth did this get through QA? Mo=
re,
> why are we still waiting for a proper fix for this?
>
> Here is another class of thoughtless "fix" implemented by Oracle in Alert
> 68. Some Oracle PL/SQL procedures take an arbitrary SQL statement as a
> parameter which is then executed. This can present a security risk. Rathe=
r
> than securing these procedures properly Oracle chose a security through
> obscurity mechanism. To be able to send the SQL query and have it execute=
d
> one needs to know a passphrase. This passphrase is hardcoded in the
> procedure and can be extracted with ease. So all an attacker needs to do =
now
> is send the passphrase and their arbitrary SQL will still be executed.
>
> In other cases Oracle have simply dropped the old procedures and added ne=
w
> ones - with the same vulnerable code!
>
> I ask again, why does it take two years to write fixes like this? Perhaps
> the fixes take this long because Oracle pore through their code looking f=
or
> similar flaws? Does the evidence bear this out. No - it doesn't. In those
> cases where a flaw was fixed properly, we find the same flaw a few lines
> further down in the code. The DRILOAD package "fixed" in Alert 68 is an
> example of this; and this is not an isolated case. This is systemic. Code
> for objects in the SYS, MDSYS, CTXSYS and WKSYS schemas all have flaws
> within close range of "fixed" problems. These should have been spotted an=
d
> fixed at the time.
>
> I reported these broken fixes to Oracle in February 2005. It is now Octob=
er
> 2005 and there is still no word of when the "real" fixes are going to be
> delivered. In all of this time Oracle database servers have been easy to
> crack - a fact Oracle are surely aware of.
>
> What about the patches since Alert 68 - the quarterly Critical Patch
> Updates? Unfortunately it is the same story. Bugs that should have been
> spotted left in the code, brand new bugs being introduced and old ones
> reappearing.
>
> This is simply NOT GOOD ENOUGH. As I stated at the beginning of this lett=
er,
> I'm concerned about Oracle security because it impinges upon me and my ow=
n
> personal security.
>
> What is apparent is that Oracle has no decent bug discovery/fix/response
> process; no QA, no understanding of the threats; no proactive program of
> finding and fixing flaws. Is anyone in control over at Oracle HQ?
>
> A good CSO needs to more than just a mouthpiece. They need to be able to
> deliver and execute an effective security strategy that actually deals wi=
th
> problems rather than sweeping them under the carpet or waste time by blam=
ing
> others for their own failings. Oracle's CSO has had five years to make
> improvements to the security of their products and their security respons=
e
> but in this time I have seen none. It is my belief that the CSO has
> categorically failed. Oracle security has stagnated under her leadership =
and
> it's time for change.
>
> I urge Oracle customers to get on the phone, send a email, demand a bette=
r
> security response; demand to see an improvement in quality. It's importan=
t
> that Oracle get it right. Our national security depends on it; our compan=
Radoslav Dejanović
> It's really a shame - but they'll only wake up when it's too late and
> MSFT, PostgreSQL and MySQL have eaten their lunch.
>
> Note: I don't care if it's Larry's personal money or Oracle's money -
> for me, this is a purely fiscal separation. In the end, the money has
> one source: Oracle.
<flame shield on>
I don't think MySQL could eat much of the Oracle cake, anyway. :)
<flame shield off>
Seriously, keep in mind that Oracle has a lot of resources, thus much=20
potential to change the course regardless of the wind direction (pun=20
intended), and they're surely not going to capsize any time soon (yeah,=20
another intended). Oracle is ahead of competition (look, another pun!) in=20
some areas; PostgreSQL has to do a lot more to prevail.
=20
However, failing in a security area is like having a hole below the=20
watermark and not caring about it because "it's small, and our boat is=20
huge". Eventually, you get full of... hmm.. water. =20
And, wasn't Oracle that company that touted their seriousness about=20
security some time ago? ;)
=2D-=20
Radoslav Dejanovi=E6
Operacijski sustavi d.o.o.
http://www.opsus.hr
Kurt Seifried
19-jul-2005 - Advisory: Various Cross-Site-Scripting Vulnerabilities in
Oracle Report - [Various CSS in Oracle Reports] (Not fixed after 700+ days)
19-jul-2005 - Advisory: Read parts of any XML-file on the application server
via Oracle Report - [Read parts of any XML file via Oracle Reports](Not
fixed after 700+days)
19-jul-2005 - Advisory: Read parts of any file on the application server via
Oracle Report - [Read parts of any file via Oracle Reports] (Not fixed after
700+days)
19-jul-2005 - Advisory: Overwrite any file on the application server via
Oracle Report - [Overwrite files via Oracle Reports] (Not fixed after 700+
days)
19-jul-2005 - Advisory: Run any OS Command via uploaded Oracle Report from
any directory- [Run any OS command via Oracle Reports] (Not fixed after 700+
days)
19-jul-2005 - Advisory: Run any OS Command via uploaded Oracle Forms from
any directory- [Run any OS command via Oracle Forms] (Not fixed after 700+
days)
Plus the last few crops of items that Oracle addressed containing items not
fixed for almost 2 years, plus the fact that their security patches often
fail to apply properly, plus the fact that their security patches now appear
to sometimes not address the problem properly if at all, plus the fact that
Oracle touts security, ran a nice big unbreakable campaign, etc, etc.
There's a ton of anecdotal evidence. There's a ton of security advisories
with notification to release times measured in years (this actually seems to
be quite normal). What more do you need? I look at open source vendors and
projects, they have become amazingly responsive (major Linux kernel issues
addressed in <1 month as a rule, often in days or a week), and even the
closed sourced vendors that formerly were problematic have gotten better in
general (Microsoft is a good example of improvement, pity they have to
maintain scuh complete backwards compatibility though or I suspect we'd see
much more improvement).
In the last 7 or so years I haven't seen much in the way of improvement from
Oracle, security-wise.
-Kurt Seifried
http://seifried.org/freescan2/