Oracle Database CVE-2018-3110
Oracle has released a security alert to address a vulnerability in multiple versions of Oracle Database that could allow a remote attacker to take control of an affected system. Waratek does not currently offer an virtual patch for CVE-2018-3110, but Waratek Security Architect Apostolos Giannakidis offers guidance on addressing this critical level vulnerability. Founder and CTO John Matthew Holt also offers his thoughts in a Q & A below.
Recommended Actions
Waratek concurs in Oracle’s recommendation that users of the impacted Oracle Database products take immediate action. CVE-2018-3110 impacts the JVM component of Oracle’s Database Server in versions 11.2.0.4 and 12.2.0.1 on Windows and version 12.1.0.2 on Windows and Oracle Database on Linux and Unix.
The first action should be to disable/remove OJVM from the RDBMS, if it is not needed. If it is needed, consider the following actions:
- Set the database password policy too enforce password complexity (see NIST Special Publication 800-63B, Appendix A).
- Take additional actions to harden the system:
- The vulnerability is exploitable by low-privileged attackers that have the “Create Session” privilege. Therefore, administrators should review the privileges that have been granted to database users and revoke the “Create Session” privilege from users that do not require it. Organizations should consider revoking this privilege from all users until the patch is applied. Note that this could cause functionality issues.
- The vulnerability is exploitable by users that have network access via Oracle Net. Therefore, Oracle customers should review which users have network access via Oracle Net and revoke access from the users that don’t require such access.
- The traffic of the users that do require network access via Oracle Net must be monitored and examined for irregular activity.
- Verify that the database users have the appropriate Java2 security permissions and database privileges to access the resources stored within the database (see Security for Oracle Database Java Applications). These resources include:
- Database resources, such as tables and PL/SQL packages
- Operating system resources, such as files and sockets
- Oracle JVM classes
- User-loaded classes
- Monitor the Oracle Database listener activity for generated alerts.
- Audit common suspicious activities. Common suspicious activities are as follows:
- Users who access the database during unusual hours
- Multiple failed user login attempts
- Login attempts by non-existent users
- Secure and harden the host operating system by disabling all unnecessary operating system services.
Commentary
from Waratek Founder and CTO, John Matthew Holt
Why should Oracle users be concerned?
CVE-2018-3110 is a nearly “perfect” compromise vulnerability due to the 9.9 CVSS rating. As a result, this vuln is about as insidious as you can get: when someone pushes an exploit script into the wild, any two-penny script kiddie will be able to take hostage one of the most popular and widespread database systems in use by companies and governments world-wide, in a single click.
How easy or difficult is it for someone to exploit CVE-2018-3110?
It’s officially rated by Oracle as having the lowest attack complexity rating on the CVSS 3.0 RISK Scale. In other words, vulnerabilities don’t get any easier than this to exploit! What this means in practice is a simple static script is all that is required – and as soon as one is released into the wild – then anyone can wield this vuln with a single click.
What, if any, are some of the conditions that need to exist for an attacker to be able to exploit the flaw (e.g. – what kind of access would the attacker need for instance?).
Only one condition is required and that is access to create a session. An attacker will need to first position themselves to open a session with the database before they can use this vuln. That may make the vuln less likely to be exploited by external actors without access to creating a session. For most organizations, the principal risk will be internal actors, such as rogue employees, or external attackers who have compromised lateral systems on the internal corporate network.
In general, how long do organizations typically take to patch security holes in Oracle and other databases (given the concerns people have over patch reliability and of disrupting production systems)?
Ages! Oracle themselves claim that their average customer runs nearly a year beyond in applying critical patches. Other third-party software testing vendors claim that 86% of even the most serious flaws take more than 30 days to fix. Yet, attackers using automated scanners can identify targets and launch attacks within hours of a vulnerability and patch being announced.
Do you have any other comments on database patching/vulnerabilities to offer?
Waratek does not currently offer patches for the Oracle Database product, but we do offer a robust “no downtime / no source code change” patching solution for Java and .NET applications. We will offer database protection in the future.
Nevertheless, this is not the last time we are likely to see similar broad vulnerabilities revealed in ubiquitous software. In fact as our connected world gets more connected, more vulnerabilities will be found, they’ll be found more frequently, and they’ll be exploited faster every time.
New solutions to the “patching problem” are desperately needed by the security community. What the industry is doing today — manual patching — doesn’t work: it takes too long, is too disruptive, and costs too much.
The result? Millions of unpatched software, libraries, platforms, and services running mission critical workloads in virtual every organization in every industry.
The “patching problem” really is the forgotten child of the IT security industry. Where there have been billions of dollars of investment and innovation in network security, endpoint security, virus scanners and so on, there has historically been no innovation in solving the “patching problem.”
In the last 2 years that has changed: Waratek’s solution to the patching problem has begun to be adopted by some of the largest enterprises in the world for solving the patching problems in the most neglected parts of the IT software supply chain — application libraries, middleware services, and runtime platforms. Using the JIT compiler present in almost all contemporary languages and application platforms, Waratek applies patch changes in real-time while the application runs as part of the normal JIT compilation pipeline for the application.
Unlike manual patching where new binary artefacts have to be uploaded to endpoints and applications have to be shut down and tested manually, virtual JIT compiler patching solutions literally provide instant patching with hard guarantees of binary compatibility, zero false positives, and zero downtime. For many mission critical application, this new form of virtual patching is the only way for that application to achieve patch compliance and be removed from red-lists of corporate risk registers and auditor penalties.
