Oracle users: you got off easy this time.
As part of its January Critical Patch Update (CPU), Oracle has released updates for
26 different issues affecting its applications. The January tally is nearly half of what Oracle usually updates in its last CPU, which came out in October of 2007.
The bulk of the fixes this time is related to Oracle’s Database products. In total, Oracle is patching for eight different security fixes related to Oracle’s Databases, though none is tagged with the “remotely exploitable without authentication” flaws.
The “remotely exploitable without authentication” flaws are among the most dangerous because, as the title implies, they can be remotely exploited by an attacker without authentication. Oracle first began providing details on which flaws could be exploited this way in October of
2006 when it patched 101 flaws, over half of which were labeled as remotely exploitable.
The January 2008 CPU also contains 7 new security fixes for the Oracle E-Business Suite, 3 of the vulnerabilities may be remotely exploited without authentication.
Oracle Application Server gets 6 security fixes, 5 of them being remotely exploitable. Oracle PeopleSoft Enterprise gets 4 security fixes with 1 remote exploit. Rounding out the list is 1 fix for the Oracle Collaboration Suite.
While Oracle has managed to reduce the patch load with the January CPU, some have argued that Oracle users aren’t paying as much attention to CPU’s as they should. Database security vendor Sentrigo reported that most Oracle users don’t actually patch their systems with the CPU.
There are a number of different reasons why Oracle DBAs (database
administrators) might be lax in updating with the Oracle’s CPU’s.
Ryan Barnett, director of training with Breach Security told InternetNews.com that the biggest challenge to applying CPU patches sets seems to be the extensive regression testing that is involved. Barnett commented that many organizations have mission critical systems that employ many different technologies and versions of those technologies.
“You would be hard pressed to find many organizations that run a heterogeneous Oracle shop – all running the exact same version- and without any custom code built around it,” Barnett said. “While everything functionality-wise is working, it is a delicate balance when any code changes or updates are made.”
Barnett argued that if vendors were to put themselves into their customers’
shoes and look at the issue of patches, they might have a different outlook.
“Vendors need to understand that due to errors within their code, not only are they putting their customers at risk of compromise but that they are also costing them money when they have to expend resources to patch their systems,” Barnett said. “With this in mind, vendors should be doing everything they can do to help provide options for their customers to remediate these issues with alternative workarounds. ”
On a year-over-year basis, Oracle has reduced its patch load by an even more significant margin of 68 percent. In its January 2007 CPU, Oracle fixed 82 flaws.
