June 29, 2017

Oracle Slips How To Attack Own Databases

Oracle is trying to figure out two things: who published information about a security flaw in their databases on their Metalink knowledgebase before they had a patch for it; and how to get out a patch for the flaw as quickly as possible.

Information about the privilege escalation vulnerability was leaked late last Thursday afternoon (April 6th). The information included data about the unfixed security flaw and exploit code that affects Oracle versions 9.1.0.0 through 10.2.0.3, or pretty much all of them.

German security investigators from Red Database Security discovered the accidental announcement and informed Oracle that releasing the information before having a patch was probably a bad idea.

Oracle agreed and took down the notice, but not before taking some heat over past criticisms the company has made about releasing exploit codes before patches are available.

Author of the Red Database Security alert Alexander Kornbrust noted that since the publishing of detailed information about the vulnerability, the flaw should be considered public knowledge so affected parties can take steps to avoid or mitigate the risk.

Details as listed on the alert:

In Oracle versions (9.1.0.0-10.2.0.3) exists an unpatched vulnerability which allows users with “SELECT” only privileges on a base table to insert/update/delete data via a specially crafted view.

The impact can be huge and eliminate the entire role concept because in well designed applications there is normally a read-only role for low-privilege users (e.g. reporting or external auditors). If these low-privileged users are able to create a view, which is standard in Oracle 9.1.x to 10 g R1, they could also insert, update and delete data via a specially crafted view. Depending on the architecture of the application, it is possible to modify data, escalate privileges (e.g. change database passwords, …), …

Workarounds / Risk Mitigation:

Sanitize the connect role (9i – 10g R1) and remove the CREATE VIEW (and CREATE DATABASE LINK, …) privilege from the connect role.

The Oracle Metalink note recommends creating views the option “WITH CHECK OPTION”. This recommendation helps against accidental modification but not against hackers.

ZDNet confirmed the accidental release with Oracle:

“Information regarding a security vulnerability was inadvertently posted to MetaLink,” a representative for the company said Tuesday. “We are currently investigating events that led to the posting.”

Though a Critical Patch Update is scheduled for release next week, the company could not say whether it would have a patch for this flaw ready in time, a topic on which Kornbrust also expressed doubt.

“We plan to provide our customers a patch that addresses this vulnerability in a future quarterly Critical Patch Update,” the Oracle representative said.

The security risk rating varies between security organizations. Red Database rates the flaw as “high risk” because of the lack of an available patch; FrSIRT rates it “moderate risk;” and Secunia downgrades it to “less critical” because attackers have to have access to the system.

Mike Murray, Director of Vulnerability Research for nCircle, was surprised by Oracle’s mistake.

“Oracle just made the security environment a lot worse for their customers -they really just shot themselves in the foot by inadvertently announcing a zero day vulnerability against themselves,” he said via email.

“Oracle products are less secure than when no one knew about this vulnerability – the lesson for other vendors is that you have to protect vulnerability information as though it is system critical information, because it is.”

About SecurityProNews Staff 1100 Articles
SecurityProNews is a daily online and email publication focusing on internet security issues.