<<< Date Index >>>     <<< Thread Index >>>

RE: Oracle, where are the patches???



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