Here is a brief analysis of thefor the upcoming April 2008 Oracle Critical Patch Update (CPU) -
In the Oracle pre-release announcement for the April 2008 Critical Patch Update, one line in particular did catch my attention. I know Oracle has purchased many companies in the past few years. So how many products does Oracle have? Well, the CPU pre-release announcement states that --
For those of you not familiar with COLLABORATE or have not previously attended, the Oracle Applications Users Group (OAUG), Independent Oracle Users Group (IOUG), and Quest have teamed together to host a user-driven event with exceptional content. COLLABORATE 08 is next week, Sunday, April 13 through Thursday, April 17 in Denver. This year there will be over 500 technical sessions covering virtually every Oracle product.
A point of contention and confusion regarding Oracle Critical Patch Update (CPU) database patches is that only a limited set of database patchsets are supported. For the January 2008 CPU, only the patchsets 184.108.40.206, 10.1.0.5, 10.2.0.2, 10.2.0.3, and 220.127.116.11 are supported. Oracle's policy is stated in the CPU Frequently Asked Questions (FAQ) (Metalink Note ID 360470.1) -
An issue in applying Oracle Critical Patch Update (CPU) database security patches has been that the patches may include non-security related fixes. The list of bugs fixed in the database patch readme is cryptic at best and it can be difficult to to determine the true impact of a specific CPU patch. By including non-security related fixes in the CPU patch reduces the confidence that the patch will not break something.
Since several new Oracle exploits were published this week, I thought it would be a good time to provide some background on exploits.
This quarters Oracle Critical Patch Update (CPU) was released on Tuesday, January 15th. In order to provide a better understanding of the CPU, I will be presenting an Oracle Applications Users Group (OAUG) eLearning session on Thursday. The presentation will focus on the impact to Oracle E-Business Suite environments.
Thursday, January 17 at 9:00 am and 5:00 pm U.S. Eastern Time
Oracle released the thirteenth Critical Patch Update (CPU) today. This quarter is the same as the previous twelve with many patches and long hours in order to get all the security patches applied in a timely manner. 17 of the 27 vulnerabilities fixed impact Oracle E-Business Suite 11i. Fortunately like the last few quarters, this quarter there are no new Oracle Application Server or Developer 6i patches required for the Oracle E-Business Suite 11i.
Here is a brief analysis of thefor the upcoming January 2008 Oracle Critical Patch Update (CPU) -
As part of the Oracle quarterly Critical Patch Update (CPU) process, a new reminder e-mail of the upcoming CPU is being sent to all individuals who signed up for e-mail notifications on the CPU web page. This e-mail is only a reminder that the next CPU will be released on January 15, 2008 (sometime after noon Pacific Time).
I do respect Oracle for being an early adopter of their own products internally, including a very large implementation of the latest Oracle E-Business Suite. Unfortunately, it appears that Oracle does not run all their products everywhere.
I recently had to revisit the estimates I provided in our white paper on brute forcing credit card hashes since new techniques were published that can speed the brute forcing up by at least a factor of 5 using off-the-shelf video cards. Well, a month later I am having to revise the estimates again. Nick Breese of New Zealand has published a paper at
From the Integrigy servers statistics, I have known that we get hundreds of visits a day from the Oracle proxy and cache servers. Many days collectively the Oracle domains (.com, .uk, etc.) are number one. The vast majority of the hits are on blog, RSS feeds, and our whitepapers. But I have not known how Oracle actually uses this information internally. Well, now I know someone is at least reading our comments and recommendations.
When clients are deploying an unpublished supplier or customer application to the Internet for the first, they are always amazed at the sheer number of random attacks. Granted many of these are looking for PHP pages or some other long ago patched vulnerability. The question that always arises is "How did they find the server so quickly?" Well, the hackers are just searching blocks of addresses on a continual basis.
This past March, I published a white paper looking at how some applications hash credit card numbers and how vulnerable these hashes are to brute forcing. I developed a proof of concept to roughly estimate the timings (about 2 million hashes per second). Looking ahead, I estimated with additional optimization, multi-threading, and faster processors probably 50 million hashes per second is achievable.