Impact Of Oracle’s Critical Update Of 85 Vulnerabilities

Oracle released a major critical patch update that fixed 85 security issues, four of which were discovered initially by my company. Oracle contains some built-in packages and I’ve 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:

  • Privilege elevation – using SQL injection
  • Changing the status of an existing Oracle job to the system
  • 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:

  • 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.
  • 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.
  • 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.
  • 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.

SHARETweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Pin on PinterestDigg thisShare on RedditShare on TumblrShare on StumbleUponEmail this to someone

Amichai Shulman is Co-Founder and CTO of Imperva, where he heads Imperva's internationally recognised research organisation focused on security and compliance. Prior to Imperva, Amichai was founder and CTO of Edvice Security Services, a consulting group that provided application and database security services to major financial institutions, including Web and database penetration testing and security strategy, design and implementation. Amichai served in the Israel Defense Forces, where he led a team that identified new computer attack and defense techniques. He has B.Sc and Masters Degrees in Computer Science from the Technion, Israel Institute of Technology.

  • Alex Rothacker

    "..all 85 are protected by Imperva’s technology"

    All 85? Does that include the:

    – 4 issues in Oracle VM

    – 5 issues in Open Office Suite

    – 26 issues in Solaris, OpenSolaris and other Sun products?