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