Message-ID: <1C09DF36EB7A3F489633C919E741350162C757@mapibe09.exchange.xchg>
Date: Fri, 28 Apr 2006 21:17:29 +0200
From: "Kornbrust, Alexander" <ak@...-database-security.com>
To: "Cesar" <cesarc56@...oo.com>,
	"David Litchfield" <davidl@...software.com>,
	"Steven M. Christey" <coley@...re.org>
Cc: <bugtraq@...urityfocus.com>
Subject: 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@...cle.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@...-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@...oo.com]
> Sent: Friday, April 28, 2006 6:33 PM
> To: David Litchfield; Steven M. Christey
> Cc: bugtraq@...urityfocus.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@...software.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

Powered by blists - more mailing lists