Bugtraq mailing list archives
RE: Recent Oracle exploit is _actually_ an 0day with no patch
From: "Kornbrust, Alexander" <ak () red-database-security com>
Date: Fri, 28 Apr 2006 21:17:29 +0200
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) isactually an 0dayand has no patch.The referenced exploit seems to useGET_DOMAIN_INDEX_METADATA with aTYPE_NAME that references an attacker-definedpackage with a(modified?) ODCIIndexGetMeta function. Your last example uses GET_V2_DOMAIN_INDEX_TABLES,with arguments thatreference an attacker-defined package with a(modified?)ODCIIndexUtilGetTableNames function. Is this a surface-level discrepancy, or is yourvector substantivelydifferent than the one in the exploit? If theseare different, thenis it possible that last week's exploit wasactually 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 atthis excruciatinglevel of detail, it seems that David's originaluse ofGET_DOMAIN_INDEX_METADATA in 2004 directlyincluded the code in theNEWBLOCK argument, whereas last week's exploit wasperformed throughan indirect reference to the code in the TYPE_NAMEargument. 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
Current thread:
- Recent Oracle exploit is _actually_ an 0day with no patch David Litchfield (Apr 26)
- <Possible follow-ups>
- Re: Recent Oracle exploit is _actually_ an 0day with no patch Steven M. Christey (Apr 28)
- Re: Recent Oracle exploit is _actually_ an 0day with no patch David Litchfield (Apr 28)
- RE: Recent Oracle exploit is _actually_ an 0day with no patch Kornbrust, Alexander (Apr 28)
- Re: Recent Oracle exploit is _actually_ an 0day with no patch David Litchfield (Apr 30)