Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Perimeter

4/27/2012
02:31 PM
Adrian Lane
Adrian Lane
Commentary
50%
50%

Security Bugs And Proofs Of Concept

Oracle's recent patch contained exploit code

Along with Oracle's recent patches for the "Security Fix: Bug #13510739" MySQL issue, a proof of concept (PoC) to excise the bug was included with the release bundle.

The bug, along with the included PoC, allows an attacker to issue a command that causes the MySQL engine to hang. It's not destructive, per se, but it will certainly cause the database to come to a halt. Any of you DBAs out there who have new DBAs/programmers on your staff know that a badly written query can do the same thing, but a general-purpose command that works against all unpatched MySQL databases could be a problem -- especially if your bonus is tied to "uptime."

The inclusion of test code is not unusual. It's entirely normal -- in fact, it's encouraged for software development teams to write PoC code to illustrate bugs and then use that code during regression testing to verify that bugs are indeed fixed. As companies fix problems, be it security or general bugs, they need PoC code for the purpose of verification.

But that's where the similarities between a normal bug and a security bug stop, at least from the perspective of software development organizations. When it comes to security, the general attitude is that sharing sample code merely educates the unwashed masses on how to exploit a vulnerability that they themselves are incapable of producing.

You'll notice that even the vocabulary software firms use when it comes to security issues changes: "Bug" becomes "Vulnerability," "Test" becomes "Attack,""Proof of Concept" vs. "Weaponized Exploit," and so on. Never let it be said that software firms are not effective marketers, because they've single-handedly remessaged security-related defects. Granted, bugs used to be an issue between software users and their vendors; security bugs allow third parties to participate, generating even more mayhem than the simple lack of intended functionality. But this added element of chaos has really pushed software quality issues into mainstream media, forcing software development firms to take security seriously, and, overall, the industry produces better software with more formalized testing and release management processes.

In this specific case with Oracle, leaking PoC code with the patch should not be a big deal, except for select firms that use MySQL in public-facing production environments and fail to patch in a timely fashion. Under these conditions, they run the risk that the defect will be discovered, the database will be brought down, and the customer will be forced to patch before operations resume. In other cases, the public disclosure could have put organizations under the gun to patch immediately lest their servers go down.

I am certain that the bundling of sample test code was a simple mistake, but that poor engineer will cause a lot of heat inside Oracle, especially given Oracle's posture against disclosure. (Read a recent post titled "Pain Comes Instantly," where Mary Ann Davidson argues against disclosure -- even to partners or customers.)

But I think it's worth raising a couple of issues here concerning database security, and feel that this disclosure cannot easily be characterized as good or bad. First, there is the general idea that no one else outside of the software firm and the customer that reported the issue knows about the security bugs. The fact is that we're finding out, through various APT attacks, black hat disclosures, and breaches that people outside the software development companies are already aware of these issues and disclose as it suits their needs.

Second, there are good reasons to share these PoCs with their customers: They can modify these test cases to their organizations to verify they are not vulnerable, or create rules/policies that can be used to block the specific attack signatures. For every argument against sharing, I can come up with another in favor of it. Equally ironic, the damage caused by disclosures seems important to select companies in the short term, whereas over the long term, sharing information on threats and vulnerabilities appears beneficial to the community at large.

I think we are going to hear a lot more about this in the coming months as I receive more rumors of known database exploits that have yet to be patched.

Adrian Lane is an analyst/CTO with Securosis LLC, an independent security consulting practice. Special to Dark Reading. Adrian Lane is a Security Strategist and brings over 25 years of industry experience to the Securosis team, much of it at the executive level. Adrian specializes in database security, data security, and secure software development. With experience at Ingres, Oracle, and ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 11/19/2020
New Proposed DNS Security Features Released
Kelly Jackson Higgins, Executive Editor at Dark Reading,  11/19/2020
How to Identify Cobalt Strike on Your Network
Zohar Buber, Security Analyst,  11/18/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: A GONG is as good as a cyber attack.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-25660
PUBLISHED: 2020-11-23
A flaw was found in the Cephx authentication protocol in versions before 15.2.6 and before 14.2.14, where it does not verify Ceph clients correctly and is then vulnerable to replay attacks in Nautilus. This flaw allows an attacker with access to the Ceph cluster network to authenticate with the Ceph...
CVE-2020-25688
PUBLISHED: 2020-11-23
A flaw was found in rhacm versions before 2.0.5 and before 2.1.0. Two internal service APIs were incorrectly provisioned using a test certificate from the source repository. This would result in all installations using the same certificates. If an attacker could observe network traffic internal to a...
CVE-2020-25696
PUBLISHED: 2020-11-23
A flaw was found in the psql interactive terminal of PostgreSQL in versions before 13.1, before 12.5, before 11.10, before 10.15, before 9.6.20 and before 9.5.24. If an interactive psql session uses \gset when querying a compromised server, the attacker can execute arbitrary code as the operating sy...
CVE-2020-26229
PUBLISHED: 2020-11-23
TYPO3 is an open source PHP based web content management system. In TYPO3 from version 10.4.0, and before version 10.4.10, RSS widgets are susceptible to XML external entity processing. This vulnerability is reasonable, but is theoretical - it was not possible to actually reproduce the vulnerability...
CVE-2020-28984
PUBLISHED: 2020-11-23
prive/formulaires/configurer_preferences.php in SPIP before 3.2.8 does not properly validate the couleur, display, display_navigation, display_outils, imessage, and spip_ecran parameters.