Cesar, David and Steve,
I agree with your opinion. Oracle is not really fast fixing security
issues.
Currently I have 40+ OPEN/UNFIXED security issues in Oracle products. A
detailed list from Oracle secalert (Report March 2006) can be found at
the end of this email or (the latest version) on my webpage:
http://www.red-database-security.com/advisory/upcoming_alerts.html
Let's do some math. According to Mary Ann Davidson 75 % of all security
bugs are found by Oracle employees: If bugs are fixed independently by
the reporter then
25 % = 40 unfixed bugs ( found by Red-Database-Security)
75 % = 120 unfixed bugs ( found by Oracle employees)
==> 160 security bugs are still unfixed.
If Cesar, Esteban and David have a similar number of open security bugs,
25 % = 100 unfixed bugs ( ESTIMATED: reported by Argeniss,
NGS and RDS)
75 % = 300 unfixed bugs ( reported by Oracle employees)
==> 400 (!!!) security bugs in Oracle are still unfixed.
UNBREAKABLE...
Regards
Alexander
--
Red-Database-Security GmbH
http://www.red-database-security.com
#############
-----Original Message-----
From: Oracle Security Alerts [mailto:secalert_us@oracle.com]
Sent: Tuesday, March 14, 2006 7:29 PM
To: Kornbrust, Alexander
Subject: Status of Red Database Security open vulnerability reports
The following is a list of all open issues that you have reported to us,
and
their current status.
____________________________________________________
Reporter: Alexander Kornbrust (ak@red-database-security.com)
Organization: Red Database Security
____________________________________________________
Tracking #: 2005-S050E
Description: plaintext password exposure using xxx
Status: Under investigation / Being fixed in main codeline
Tracking #: 2005-S066E
Description: xxx plaintext password in xxx
Status: Issue fixed in main codeline, scheduled for a future CPU
Tracking #: 2005-S067E
Description: xxx plaintext password in xxx
Status: Issue fixed in main codeline, scheduled for a future CPU
Tracking #: 5448895
Description: xxx ARE RUN AS SYS WHEN USING xxx
Status: Issue fixed in main codeline, scheduled for a future CPU
Tracking #: 5883663
Description: XSS in Oracle xxx using xxx and xxx
Status: Issue fixed in main codeline, scheduled for a future CPU
Tracking #: 5883665
Description: XSS in Oracle xxx using xxx and xxx
Status: Issue fixed in main codeline, scheduled for a future CPU
Tracking #: 6343787 (Duplicate -- Previously reported)
Description: xxx CROSS SITE SCRIPTING VULNERABILITY USING xxx
Status: Issue fixed in main codeline, scheduled for a future CPU
Tracking #: 6343935 (Duplicate -- Previously reported)
Description: CROSS SITE SCRIPTING IN xxx
Status: Issue fixed in main codeline, scheduled for a future CPU
Tracking #: 6454153
Description: SQL INJECTION VULNERABILITY IN xxx USING xxx
Status: Issue fixed in main codeline, scheduled for a future CPU
Tracking #: 6454409
Description: xxx CAN BE BYPASSED USING xxx
Status: Under investigation / Being fixed in main codeline
Tracking #: 6543483
Description: SECURITY GUIDE NEEDS TO DOCUMENT DANGERS OF xxx
Status: Under investigation / Being fixed in main codeline
Tracking #: 6543923
Description: xxx
Status: Under investigation / Being fixed in main codeline
Tracking #: 6914665
Description: xxx CAN CRASH (POSSIBLE BUFFER OVERFLOW) IF HANDCRAFTED
PACKET PRESENTED
Status: Issue fixed in main codeline, scheduled for a future CPU
Tracking #: 6980695
Description: SQL Injection in xxx
Status: Issue fixed in main codeline, scheduled for a future CPU
Tracking #: 6980701
Description: SQL Injections in xxx
Status: Issue fixed in main codeline, scheduled for a future CPU
Tracking #: 6980711
Description: SQL Injections in xxx
Status: Issue fixed in main codeline, scheduled for a future CPU
Tracking #: 6980717
Description: SQL Injection in xxx
Status: Issue fixed in main codeline, scheduled for a future CPU
Tracking #: 6980725
Description: SQL Injections in xxx
Status: Issue fixed in main codeline, scheduled for a future CPU
Tracking #: 6980733
Description: SQL Injections in xxx and xxx
Status: Issue fixed in main codeline, scheduled for a future CPU
Tracking #: 6980737
Description: SQL Injections in xxx
Status: Issue fixed in main codeline, scheduled for a future CPU
Tracking #: 6980745
Description: SQL Injection in xxx
Status: Issue fixed in main codeline, scheduled for a future CPU
Tracking #: 6980751
Description: SQL Injections in xxx
Status: Issue fixed in main codeline, scheduled for a future CPU
Tracking #: 6980753
Description: SQL Injections in xxx
Status: Issue fixed in main codeline, scheduled for a future CPU
Tracking #: 6980761
Description: SQL Injections in xxx
Status: Issue fixed in main codeline, scheduled for a future CPU
Tracking #: 6980765
Description: SQL Injection in xxx
Status: Issue fixed in main codeline, scheduled for a future CPU
Tracking #: 6980771
Description: SQL Injections in xxx and xxx
Status: Issue fixed in main codeline, scheduled for a future CPU
Tracking #: 6980775
Description: SQL Injection in xxx
Status: Issue fixed in main codeline, scheduled for a future CPU
Tracking #: 6980781
Description: SQL Injections in xxx
Status: Under investigation / Being fixed in main codeline
Tracking #: 6980783
Description: SQL Injection in xxx
Status: Under investigation / Being fixed in main codeline
Tracking #: 6980789
Description: SQL Injection in xxx
Status: Under investigation / Being fixed in main codeline
Tracking #: 6980793
Description: SQL Injections in xxx
Status: Under investigation / Being fixed in main codeline
Tracking #: 6980797
Description: SQL Injections in xxx
Status: Under investigation / Being fixed in main codeline
Tracking #: 6980807
Description: SQL Injections in xxx
Status: Under investigation / Being fixed in main codeline
Tracking #: 6980813
Description: SQL Injection in xxx
Status: Under investigation / Being fixed in main codeline
Tracking #: 6980817
Description: SQL Injection in xxx
Status: Under investigation / Being fixed in main codeline
Tracking #: 6980819
Description: SQL Injection in xxx
Status: Under investigation / Being fixed in main codeline
Tracking #: 6980825
Description: SQL Injection in xxx
Status: Under investigation / Being fixed in main codeline
#############
-----Original Message-----
From: Cesar [mailto:cesarc56@yahoo.com]
Sent: Friday, April 28, 2006 6:33 PM
To: David Litchfield; Steven M. Christey
Cc: bugtraq@securityfocus.com
Subject: Re: Recent Oracle exploit is _actually_ an 0day with no patch
David is right, we also have reported hundreds of
vulnerabiities to Oracle and they only fix what you
report to them, they don't care to fix the same
vulnerability on different portions of code, one good
example is that Oracle should have eliminated SQL
injection bugs since long time ago but there are still
SQL injection bugs all around because they only fix
bugs reported by researchers. I remember Mary Ann
Davidson saying "Oracle finds more than 75 percent of
significant security vulnerabilities in-house"
(http://news.com.com/When+security+researchers+become+the+problem/2010-
1071_3-5807074.html)
so WTF you don't fix them!!!!!
I really can't understand how customers don't demand
better security to Oracle or switch to other vendor, I
would like to have customers like that so you can sell
very unsecure products to them and them won't ever
complain so I can save billons not improving security
on products and make a lot of money$$$$.
PS: Look at this paper dated February 2002, amazing
how Oracle efforts are visible on 2006!
http://www.cgisecurity.com/database/oracle/pdf/unbreak3.pdf
Cesar.
--- David Litchfield <davidl@ngssoftware.com> wrote:
The recent Oracle exploit posted to Bugtraq
(http://www.securityfocus.com/archive/1/431353) is
actually an 0day
and has no patch.
The referenced exploit seems to use
GET_DOMAIN_INDEX_METADATA with a
TYPE_NAME that references an attacker-defined
package with a
(modified?) ODCIIndexGetMeta function.
Your last example uses GET_V2_DOMAIN_INDEX_TABLES,
with arguments that
reference an attacker-defined package with a
(modified?)
ODCIIndexUtilGetTableNames function.
Is this a surface-level discrepancy, or is your
vector substantively
different than the one in the exploit? If these
are different, then
is it possible that last week's exploit was
actually fixed?
No; the same problem occurs. This is the kind of
general problem I'm
speaking about. Most vendors that actually
understand security will look for
other bugs in the same functional area if you point
out a bug. IMO, my job
as a security vulnerability researcher is to
highlight problem areas - i.e.
areas of functionality that are rife with issues.
How can Oracle fix one
issue but miss the same flaw two lines later??? In
this case though, we're
not just talking about one flaw but several. Really,
it is inconceivable,
yet they, somehow, manage to do it.
God forbid that any of our critical national
infrastructure runs on this
product.... oops it does :(
And every version from 8 through 9 to 10 release 2
is vulnerable. That's
every supported version of Oracle on every operating
system.
Oracle customers: honestly - Oracle are not going to
listen to the likes of
me - but they will listen folks like you. If you're
not happy with the
response you're getting from Oracle then get on the
'phone - call them up
and tell them that you're not happy. Please, demand
improvements.
By the way, this is not an isolated incident. I have
many examples to hand
where Oracle have tried to fix problems in the same
functional area but only
whitewashed it. They should be proactively looking
for similar issues in the
same code just like Microsoft does.
The "champion of quality coding movement"
(http://www.cio.com/archive/031505/security.html) ,
who "applauds ethical
hacking", asks "Why isn't that standard development
process?"
I don't know... but I don't think we'll find out in
the two year time frame
posited; we've got less than a year to go.
- Steve
P.S. For those of you who are paying attention at
this excruciating
level of detail, it seems that David's original
use of
GET_DOMAIN_INDEX_METADATA in 2004 directly
included the code in the
NEWBLOCK argument, whereas last week's exploit was
performed through
an indirect reference to the code in the TYPE_NAME
argument.
p.p.s.
Just to clarify the issues:
GET_DOMAIN_INDEX_TABLES
GET_DOMAIN_INDEX_METADATA
GET_V2_DOMAIN_INDEX_TABLES
are all vulnerable to the exploit.
Cheers,
David Litchfield
NGSSoftware Ltd,
http://www.ngssoftware.com/
+44 (0) 208 401 0070
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
