• Startseite
• About
• Impressum
• Marcell published “Writing your own password cracker” presentation

8 Antworten auf “First exploits for CPUJan2008 published”

1. Gary sagt:
   31 Jan 2008 bei 23:18

   The CPU advisory stated that the XMLDB bug affected 9iR2, 10gR1 and 10gR2 and didn’t mention 11g (though it is mentioned earlier in the document as a supported release).
   I suspect all those exploits were already fixed at the time of the 11g release. Not sure whether Alexandr used differences between 11g and an earlier release to identify possible security exploits patched by 11g, but I guess someone is trying that approach.

2. Joxean Koret sagt:
   1 Feb 2008 bei 11:13

   Hi,

   Yes, Gary. These flaws were fixed in 11g prior to the release of this CPU.

   I found my self the vulnerability in 2006 (or was 2005…? I do not remember now) and, apparently, it was fixed in the next year 2007 (Issue fixed in main/scheduled for a future CPU).

   As is common with Oracle, even when it was a semi-public vuln (easily discovered by hand or by using a fuzzer as the one I released in the past) and they were aware of it from years, Oracle decided not to release patches for the issue and left vulnerable their customers.

   When 11g was released I downloaded and tested all of my vulns against that version. The vast majority of _currently unfixed_ flaws in 10g releases (fully patched) are fixed in 11g.

   If you don’t own an unwrapper you can do the following: Run the Inguma PL/SQL fuzzer against an 11g database and log the exceptions raised by DBMS_ASSERT. After it, re-run the fuzzer explicitly selecting just these packages (the ones that raised the DBMS_ASSERT errors) against one 10g (fully patched 10.2.0.3 with latest CPU) databases: You will found that many of these are vulnerable.

   Why Oracle left their customers vulnerable? Ask they, I’m only a security researcher tired of the Oracle policies….

3. Alexandr Polyakov sagt:
   1 Feb 2008 bei 15:56

   “it seems that someone else reported these errors before”

   there was advisory http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=622

   i decided to check it in Oracle 10gR1 and found 2 functions that vulnerable too. Maybe Oracle know’s about it (when testing idefense advisory) but i decided to send information about it anyvay.
   when i send advisory to Oracle they ansvered:

   ———–
   Hi Alexandr,

   We are aware of these issues and are currently working on fixes for them.
   ———–

   thats why i think they fixes vulnerabilities within less than a month.

   p.s. i have posted 4 exploits maybe you didnt see http://milw0rm.com/exploits/4997

4. Alexander Kornbrust sagt:
   1 Feb 2008 bei 17:06

   Hi Alexandr,

   sorry I missed the forth exploit. I did not saw that your exploit was different from the one published a few months ago on bugtraq. The exploit was looking so similar but another procedure was affected.

   –

   It’s not unusual that different researchers are finding / reporting the same vulnerabilities. In this case it seems that Joxean found the bugs already 2005/2006.

5. Alexander Kornbrust sagt:
   1 Feb 2008 bei 17:11

   Joxean and Alexandr

   How many open vulnerabilities do you have in the Oracle database at the moment (if this information is not a secret)?

   We have only 32 open vulnerabilities in the database (taken from the January report from secalert).

   Alexander

6. Joxean Koret sagt:
   1 Feb 2008 bei 22:12

   Hi Alex,

   I have 23 currently unfixed flaws in Oracle Database (taken, as you, from the secalert report). But that number only reflects the total vulnerabilities I reported directly. Many of these were reported to 3rd parties (iDefense and ZDI).

   Joxean Koret

7. Joxean Koret sagt:
   1 Feb 2008 bei 22:14

   Sorry for the typo:

   >Many of these were reported to 3rd parties (iDefense and ZDI).

   Many “others” were reported to 3rd parties.

   Joxean Koret

8. Log Buffer #83: a Carnival of the Vanities for DBAs sagt:
   20 Feb 2009 bei 23:18

   […] Staying with Oracle for the moment, Red Database Security’s blog reports on the First exploits for January’s CPU. […]

Antwort schreiben

Sie müssen als angemeldet sein, um einen Kommentar schreiben zu können.