Perimeter
4/27/2012
02:31 PM
Adrian Lane
Adrian Lane
Commentary
Connect Directly
RSS
E-Mail
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
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading Must Reads - September 25, 2014
Dark Reading's new Must Reads is a compendium of our best recent coverage of identity and access management. Learn about access control in the age of HTML5, how to improve authentication, why Active Directory is dead, and more.
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2003-1598
Published: 2014-10-01
SQL injection vulnerability in log.header.php in WordPress 0.7 and earlier allows remote attackers to execute arbitrary SQL commands via the posts variable.

CVE-2011-4624
Published: 2014-10-01
Cross-site scripting (XSS) vulnerability in facebook.php in the GRAND FlAGallery plugin (flash-album-gallery) before 1.57 for WordPress allows remote attackers to inject arbitrary web script or HTML via the i parameter.

CVE-2012-0811
Published: 2014-10-01
Multiple SQL injection vulnerabilities in Postfix Admin (aka postfixadmin) before 2.3.5 allow remote authenticated users to execute arbitrary SQL commands via (1) the pw parameter to the pacrypt function, when mysql_encrypt is configured, or (2) unspecified vectors that are used in backup files gene...

CVE-2012-5485
Published: 2014-09-30
registerConfiglet.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via unspecified vectors, related to the admin interface.

CVE-2012-5486
Published: 2014-09-30
ZPublisher.HTTPRequest._scrubHeader in Zope 2 before 2.13.19, as used in Plone before 4.3 beta 1, allows remote attackers to inject arbitrary HTTP headers via a linefeed (LF) character.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Chris Hadnagy, who hosts the annual Social Engineering Capture the Flag Contest at DEF CON, will discuss the latest trends attackers are using.