Actu
Imperva CTO comments on Impact of Oracle Critical Update of 85 Vulnerabilities
October 2010 by Imperva
Last night Oracle released a major critical patch update that fixed 85 new security issues, four of which were discovered initially by Imperva, all 85 are protected by Imperva’s technology. Below is a comment from Imperva’s CTO, Amichai Shulman on the patch and what system admins need to be wary about:
“Oracle contains some built-in packages, Imperva’s ADC team members, myself and Yaniv Azaria, have found one of these packages vulnerable to three different types of attacks. The malicious individual would have been able to exploit the vulnerabilities in order to achieve one of the following attack goals:
a. Privilege elevation – using SQL injection
b. Changing the status of an existing Oracle job to the system
c. Submitting a new Oracle job to the system
This latest patch from Oracle is very extensive and will need a complex process to be put into place by system admins to ensure that the patches are prioritized, tested and deployed correctly while ensuring nothing else in their systems has been affected.
The bigger the patch, the more complex the process – Successfully implementing a patch requires the following stages:
a. Assessing the exploits as mentioned in the patch. This includes understanding the details of the exploit, whether it is applicable to the enterprise, and how an attack would affect the systems.
b. Assessing the process of patching the system with the Oracle CPU. For example, how a patch would affect the system. At times a patch may be contradictory to an already existing code, or it may open some work-around. All this must first be assessed.
c. Assessing system downtime. The patching requires a system downtime where the database server cannot provide service to users in order to patch it. It is required to understand who is affected by the downtime and how long the service is not available.
d. Patching the enterprise’s system. A process is required to be put in place, esp. in enterprises which deploy hundreds of databases. This includes creating a timeline, prioritizing the databases in the order they should be patched, and reviewing the system all along. For instance, if the patch happened to break some feature, then returning to fix the system and making sure that future patching will not cause the same error.
This process should not be taken lightly. For many organizations, the process of patching lasts a few months – mainly between 3-6 months. DBAs, system and IT admins, developers – all these play a role in the patching process. As resources and time are constrained servers are left vulnerable for months after the release of a patch. Of course, the addition of more patches to different parts of the system – such as when MS patches pertain to servers, just adds complexity to the patching process.
As the process to deploy these patches can take a long time, Organisations need to ensure they are protected from these vulnerabilities even before patches are deployed by using other security products such as database activity monitoring tools.”
