David, You are right. I have only a few things to add. 1.) In the April CPU 2006 patches for 9.2.0.7, Oracle forgot to sanitize a parameter in one of the SDO packages. Oracle sanitized one parameter twice (Copy/Paste-Error). Oracle assigned a new bug number (7520291) for this issue. ==> Such bugs are a indication of a bad Q/A. 2.) 2 weeks ago I found a way to bypass dbms_assert in many cases. Oracle is already informed. This means that many Oracle packages are vulnerable again and the bugfixes against SQL Injection are often useless. I hope Oracle will fix most of the bugs until end of 2008. Here my quote of the day... http://www.computerweekly.com/Articles/2006/05/02/215721/Exploitedflawtr acedasfarbackasOracle8.htm [...] "Oracle said that since its critical patch update is tested across product suites, the company is limited in the number of fixes it can include." [...] Cheers Alexander Kornbrust Red-Database-Security GmbH http://www.red-database-security.com > -----Original Message----- > From: David Litchfield [mailto:davidl@xxxxxxxxxxxxxxx] > Sent: Tuesday, May 02, 2006 5:10 PM > To: bugtraq@xxxxxxxxxxxxxxxxx; full-disclosure@xxxxxxxxxxxxxxxxx; > ntbugtraq@xxxxxxxxxxxxxxxxxxxxxx > Subject: Oracle, where are the patches??? > > A regular patch release cycle is a good thing. It allows system > administrators to plan ahead and minimize server downtime. If I, as a > system > administrator, know that on the 18th of April 2006 a critical patch is > going > to be released I'll plan to stay late at work that night and start the > assessment of the patch before I install it. All going well, I can install > the patch and reboot the server all with a minimum amount of downtime. > This > should happen once a month or once a quarter - whatever interval my vendor > has chosen. That's what good regular patches allow me to do. The benefits > are absolutely clear. > > There are two major problems that can cause these benefits to evaporate > into > thin air, however. These are > > 1) Late Patches - If patches aren't delivered on the day they were > supposed > to be, then all my planning ahead has gone to waste and a new plan needs > to > be scheduled. > 2) Re-issued Patches - If a vendor has to reissue a patch then I have to > reinstall it - which costs me more money and more server downtime. The > more > times the patch is re-issued the more it eats into my budget. > > Since starting its regular quarterly patch release cycle Oracle has been > guilty of both. > > Most recently, Oracle informed us that on the 18th of April 2006 that > Critical Patch Update would be released. This date had been planned for > over > a year so why, on that date, were patches not ready for versions 10.2.0.2, > 10.1.0.4, 10.1.0.3, 9.2.0.5, 8.1.7.4 and only partial patches for > 10.1.0.5? > Further, patches were only available for versions 9.2.0.7, 9.2.0.6 and > 10.2.0.1 which means patches are available for only 33% of their supported > versions - what about the poor people running the other 66%? > > These 66% were told that their patches would be available on the 1st of > May > 2006. In all fairness, the 1st of May was an "Estimated Time of Arrival" - > but boy - was that estimate way off! The ETA has now been revised to the > 15th of May - a whole month after the supposed patch release day. > > What about Oracle's track record on patch re-issuance? Let's look - the > January 2006 critical patch update was re-issued seven times, the October > 2005 CPU three times and the July 2005 CPU was re-issued nine times. The > story is the same for earlier CPUs. > > Mary, Mary, quite contrary to what you'd have us believe about Oracle's > security track record, it's not looking too good from my view. > > Cheers, > David Litchfield > NGSSoftware Ltd > http://www.ngssoftware.com/ > +44 (0) 208 401 0070
