Calendar
Kategorien
- 11g (5)
- Allgemein (15)
- checkpwd (4)
- CPUApril2009 (2)
- CPUJan2009 (3)
- David Litchfield (5)
- Exploit (12)
- Forensics (4)
- Oracle Security (65)
- passwords (5)
- Security (12)
- Sentrigo (5)
- software (6)
- source code audit (3)
- SQL Injection (15)
- Tools (10)
- Trainings (1)
- Tutorial (2)
Letzte Einträge
- 16 Mai 2009: Presentation from Confidence 2009 available
- 1 Mai 2009: Perl - Script to run OS commands via Oracle based Web Apps released
- 23 Apr 2009: SQLMap 0.7 rc is out
- 21 Apr 2009: Listener Exploit (April 2009) from Dennis Yurichev published
- 20 Apr 2009: Whitepaper: Penetration from Application down to OS
- 20 Apr 2009: Pangolin 2.0.2.820 with enhanced Oracle support
- 16 Apr 2009: 3 new Oracle Security Videos
- 16 Apr 2009: SQL Injection Tool Pangolin 2.0 published
- 15 Apr 2009: Oracle Database Scanner Repscan 2.5 trial available
- 14 Apr 2009: Oracle Critical Patch Update April 2009 (CPUApr2009) is out
Links
Oracle Security
Other Blogs
SQL Injection
Trainings
Archive
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.
- SQL Injection in PITRIG_DROP (1)
- SQL Injection in PITRIG_DROP (2)
- SQL Injection in PITRIG_TRUNCATE (1)
- SQL Injection in PITRIG_TRUNCATE (2)
8 Antworten auf “First exploits for CPUJan2008 published”
Antwort schreiben
Sie müssen als angemeldet sein, um einen Kommentar schreiben zu können.

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.
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….
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
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.
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
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
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
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. […]