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
