RE: Recent Oracle exploit is _actually_ an 0day with no patch
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@xxxxxxxxxx]
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@xxxxxxxxxxxxxxxxxxxxxxxxx)
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@xxxxxxxxx]
> Sent: Friday, April 28, 2006 6:33 PM
> To: David Litchfield; Steven M. Christey
> Cc: bugtraq@xxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx> 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