First exploits for CPUJan2008 published

The first exploits for CPU January 2008 were published on milw0rm.com.

Alexandr Polyakov from Digital Security published 4 exploits for XMLDB. Alexandr found and reported these vulnerabilities mid of december 2007 to Oracle. It seems that someone else reported these errors before because Oracle NEVER fixes vulnerabilities within less than a month.

8 Responses to “First exploits for CPUJan2008 published”

  1. Gary sagt:

    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:

    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. “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. 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. 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:

    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:

    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. [...] Staying with Oracle for the moment, Red Database Security’s blog reports on the First exploits for January’s CPU. [...]

Leave a Reply

You must be logged in to post a comment.