Auditing an Oracle database for security issues is very important. PeteFinnigan.com provides all of the information and tools that you will need Click here for details of PeteFinnigan.com Limited's detailed Oracle database security audit service Click here for details of PeteFinnigan.com Limited's Oracle Security Training Courses
There are 52 visitors online    

Pete Finnigan's Oracle security weblog


Home » Archives » July 2005 » Same problem again as April CPU - CPU July 2005 failed to fix a bug it says it did fix

[Previous entry: "Oracle Simplifies SOA Security"] [Next entry: "Grant talks about securing Forms applications with SSL"]

Same problem again as April CPU - CPU July 2005 failed to fix a bug it says it did fix

July 14th, 2005 by Pete

Post to del.icio.us   Post to Furl   Digg!

I got an email this afternoon from Cesar Cerrudo of Argeniss about my post yesterday "SearchSecurity.com has a good news story about CPU July 2005" - Cesar was quoted in the news article as saying that his opinion was that Oracle's CPU patches should not be applied to production until they had been tested for a few months first. Cesar wanted to comment further on my point that it is better to install the patch now even if it could have problems like the CPU April patch did. I said even if something is not fixed it is better to at least have fixes for the other issues that are corrected properly. Cesar said this to me;

"I know that applying a patch no matter if it won't fix some vulns it's better to not installing at all, but this is on a "perfect world" which is far from "Oracle world". Basically i recommended to not install the Oracle patch because April CPU failed to fix some bugs and this "clearly" indicates that Oracle is not doing at all QA on patches! so the better thing that can happen to you is that the patch fails to fix a bug, but what about if after you applied the patch the system doesn't work any more and you have to have a production system down for a couple of hours, i know this is an extreme scenario but on "Oracle world" this could happen, people must be very careful when applying Oracle patches."

I can see Cesar's point but I think I would still say that applying the security patches earlier to production, rather than waiting for months for thorough testing is a risk that has to be taken. If a patch fixes 50 bugs (I know litterally no one would benefit from all 50 bug fixes due to product choices and implementations) then most customers would get quite a few fixes. But Cesar is right to worry about any other risks of applying patches without testing first. The biggest risk of all is that you can take a risk to apply the patch and then find that it did not actually fix the bugs it was supposed to. This is what Cesar went on to tell me:

"Let me tell you a little secret, guess what? Oracle did it again! July CPU doesn't fix one of the bugs on 9iR2 but it does fix it on 10g, the risk matrix is wrong because it says that the Earliest Supported Release Affected is 10g but 9iR2 is affected(prior versions could be affected also, we are still working on this), so Oracle has left 9iR2 users unpatched, we will release more info about this later."

This is bad news for this CPU. I for one am looking to Cesar and his guys to release information on this quickly so that everyone can get a new fix from Oracle.

July 2005
SMTWTFS
     12
3456789
10111213141516
17181920212223
24252627282930
31      

This is the weblog for Pete Finnigan. Pete works in the area of Oracle security and he specialises in auditing Oracle databases for security issues. This weblog is aimed squarely at those interested in the security of their Oracle databases.

Weblog Home
Weblog Archives

Oracle Security Step-by-Step (Version 2.0)

Home
Oracle Security Tools page
Oracle security papers
Oracle Security alerts

Web Development
SQL Server Security

RSS 1.0 FEED
RSS 2.0 FEED
Atom 0.3 FEED
Powered by gm-rss 2.0.0




View Pete Finnigan's profile on LinkedIn

Pete Finnigan

Create Your Badge



Valid XHTML 1.0!