- 10.2.0.4 (1)
- 11g (3)
- Allgemein (11)
- BEA (1)
- checkpwd (4)
- CPUApr2008 (3)
- CPUJan2008 (2)
- CPUJul2007 (3)
- CPUOct2007 (1)
- Database Vault (1)
- David Litchfield (4)
- Exploit (4)
- Forensics (3)
- Inguma (2)
- MacOS (1)
- Mary Ann (1)
- Oracle (2)
- Oracle Security (46)
- passwords (3)
- Podcast (1)
- rootkits (1)
- Security (9)
- Security Book (1)
- Sentrigo (1)
- software (2)
- Source Code Analysis (1)
- source code audit (3)
- SQL Injection (4)
- Trainings (1)
- 9 Aug 2008: July 2008 CPU Advisory - Windows Patch update for Oracle 10.1.0.5
- 29 Jul 2008: Exploit for Oracle Bea Weblogic - Apache Connector published
- 8 Mai 2008: Checkpwd 1.23 for MacOS Intel native released
- 16 Apr 2008: Oracle CPU April 2008 - Update
- 15 Apr 2008: Oracle Critical Patch Update April 2008 is out
- 11 Apr 2008: Looking Glass and Oracle 11g
- 11 Apr 2008: Oracle Critical Patch Update Pre-Release Announcement - April 2008
- 4 Mrz 2008: We proudly present: Anna Marie Kornbrust
- 4 Mrz 2008: Corba Exploit for VisiBroker published
- 25 Feb 2008: Oracle Patchset 10.2.0.4 is out
Oracle CPUs and problems on some platforms
During our security training we found an interesting forum entry (CPU Oct 2006 Problem) in Oracle Metalink. It seems that a portscan with nmap on AIX 5.2, OAS 10.1.2.0.2 CPUOCT06 causes a denial of service problem on port 443 (HTTPS). It’s not clear if this problem affects all platforms because nobody answered the forum entry.
Normally it is a good idea to apply CPUs as soon but sometimes new bugs are introduced. Often these problems are specific to a special platform. Another example of a bug which was introduced by the CPUOct2006, CPUJan2007 and CPUApr2007 was a rman problem on Windows 32 bit (Rman fails to restore in 9.2.0.8 with CPU patch installed on Windows platform).
Before applying a patch on a production system you should always perform tests.
15 Jun 2007 bei 05:25
“Before applying a patch on a production system you should always perform tests.”
So, what are we supposed to test?
The entire application set that may be executing in a server?
Every time a CPU comes out? And who pays for that testing? Do we get a discount on the maintenance fees of Oracle for that?
Or is it that we should run every possible command available against any resource that the database might be using? As in running nmap, an obvious (not!) choice for testing after a patch is applied?
No thanks, that is very simply not the solution.
I’ll take the obvious, sensible and much cheaper option: NONE of the CPUs are ever applied to my systems!
I’ll apply patches to specific problems, when and if found. Rather than pay through the nose to trace Oracle’s own problems…