Category Archives: Security

MySQL 0-Days: CVE-2012-5611 to 5615

A set of MySQL 0-Day vulnerabilities has been posted on the full-disclosure list with CVEs already assigned, as explained by Red Hat’s SRT

So normally for MySQL issues Oracle would assign the CVE #. However in this case we have a bit of a time constraint (it’s a weekend and this is blowing up quickly) and the impacts are potentially quite severe. So I’ve spoken with some other Red Hat SRT members and we feel it is best to get CVE #’s assigned for these issues quickly so we can refer to them properly.

If Oracle security has already assigned CVE’s for these please let us and the public know so we can use the correct numbers. Also if Oracle can let the public know which versions of MySQL are affected (e.g. 5.0.x, 5.1.x, 5.5.x, etc.) that would be very helpful to everyone I am sure.

So far it appears from the MariaDB response and update notice (Oracle has yet to respond) that CVE-2012-5611 will be deprecated as a duplicate of CVE-2012-5579 but 5612 and 5614 require patches. 5615, a user disclosure issue, received this response from MariaDB

hardly a ‘zeroday’ issue, it was known for, like, ten years

And, last but not least, 5613 is a point of configuration.

The MySQL 5.0 Reference Manual Security Guidelines clearly state “Do not grant the FILE privilege to nonadministrative users” but someone may still make that mistake, as demonstrated in this video by Eric Romang

Still no word from Oracle…but MariaDB speculates on their behalf that their next releases shouldn’t be vulnerable to the CVE that they know about.

At a time when trust and transparency are more in demand than ever, security lists indicate a continuing trend in what some have described as this:

Oracle’s lack of communication regarding the future…

Algorithms, DVD CSS and Haiku

My mother dropped off a book for me to read called “Coding Freedom: The Ethics and Aesthetics of Hacking” by Gabriella Coleman.

The section on poetic protest within the chapter “Code is Speech” reminded me of the haiku called

How to decrypt a
DVD, in haiku form
Thanks, Prof. D. S. T.

A quick search for the original text of the poem brought me to an interesting backstory by its author, Seth Schoen:

A strange tradition current among programmers calls for the use of the 5-7-5 pattern — preferably cleverly — to express technology, or jokes about technology, or really anything at all, just for the fun or the challenge of writing within the constraint. I remember particularly that the UC Berkeley Computer Science Undergraduate Association has a mysterious tradition of writing haiku poems about the chemical element zinc. The tradition seemed to start with a 1995 transcript of a conversation in which CS students began to write poems about zinc, but it continued within and without the Berkeley CSUA, and I know that I personally helped spread the tradition to other forums and communities.

[…]

It’s clear that the practice of writing 5-7-5 verses and calling them “haiku” seizes on only one aspect of the haiku form and entirely removes it from its original cultural context. I freely admit that my poem has no cultural continuity with the ancient Japanese haiku artform, although I think it has its own sort of literary merit.

Well, maybe if the ancient Japanese had DVD CSS to deal with…but seriously, poetry often can be revealing and controversial through indirect methods. It can be a backdoor of communication on subjects where the front door is sealed. There is perhaps more continuity than Schoen realizes.

Why South Carolina’s Governor wants encryption NOW

The leader of an American state is in the news advocating encryption be added to government compliance requirements. She has pointed blame for a serious breach of confidentiality, under her watch, towards her regulators.

Gov. Nikki Haley’s remarks on Tuesday came after a report into the breach revealed that 74.7 GB was stolen from computers belonging to South Carolina’s Department of Revenue (DOR) after an employee fell victim to a phishing email.

First, her remarks feel slightly off the mark to me. The incident response report released by her office asserts only a correlation between a phishing email and the breach.

The report very cleary states causation was not found.

The malware likely stole the user’s username and password. This theory is based on other facts discovered during the investigation; however, Mandiant was unable to conclusively determine if this is how the user’s credentials were obtained by the attacker.

The news I have seen consistently refers to a case of malware through phishing, even though the IR report warns that it is only “likely.”

Beware the difference.

Why does certainty matter so much here? Because encryption has a well-known and significant weakness: an attacker who can compromise credentials needed for decryption still can steal 74.7GB of confidential data. The strength of a safe’s walls are far less relevant if a front door is left open.

Second, if an executive passing the blame on to regulators sounds familiar it might be because Heartland’s CEO used similar rhetoric.

In the post-Enron environment, the auditors have contracts with clients that essentially absolve them of gross negligence. The false reports we got for 6 years, we have no recourse. No grounds for litigation. That was a stunning thing to learn. In fairness to QSAs, their job is very difficult, but up until this point, we certainly didn’t understand the limitations of PCI and the entire assessment process. PCI compliance doesn’t mean secure. We and others were declared PCI compliant shortly before the intrusions.

Most people might think Enron was a lesson in detecting executive negligence and fraud. A CEO saying the case centers on “gross negligence” by auditors paints an interesting perspective on management responsibility as well as history.

Consider this brief definition of gross negligence for a physician:

Gross negligence evinces a reckless disregard for the rights of others or smacks of intentional wrongdoing. In other words, gross negligence is an act or omission of an aggravated character, as distinguished from the failure to exercise ordinary care.

Heartland’s CEO appears to equate a breach of his systems to this kind of intentional wrongdoing, perhaps even intent to decieve, by those meant to help him assess his compliance with a regulation.

Enron, however, was a very different case. As Time magazine explained in 2002, auditors were found guilty of charges they helped executives of Enron hide risk from the regulators. Executives and auditors were thought to be in cahoots.

Said prosecutor Andrew Weissman: “This is a perfect example of Arthur Andersen sanitizing the record so the SEC would have less information.”

It might be useful to also mention that Enron’s auditing firm later was found not-guilty and the conviction overturned by unanimous Supreme Court decision (Andersen v. U.S., 04-368).

At trial, Andersen argued that employees who shredded tons of documents followed the policy and there was no intent to thwart the SEC investigation.
[…]
A ruling against Andersen could have had onerous consequences for businesses, whose discarding of files is an everyday occurrence. Experts say companies would have had to keep all files for fear that any disposal, however innocent, could subject them to potential prosecution.

In other words the core Enron lesson has to do with the executives intentionally misleading regulators with the help of those working for them. The Andersen case related to questions of client-independence and retention policies with oversight by regulators. The Heartland CEO characterizes the problem as executives who didn’t realize they were comitting fraud rather than asking why no one blew the whistle on Enron executives.

Back to South Carolina’s Governor, she was quick to throw mud at her regulators: “This is a new era in time where you can’t work with 1970 equipment. You can’t go with compliance standards of the federal government.” See the whole mud-slinging event here:

What she says is true to some degree, you can’t go with compliance standards of the federal government to be safe any more than you can take the South Carolina driving test and assume you will be safe on the road. A fair amount of driver intervention is required.

So if a driver has an accident should we expect them to say “…you can’t work with 1970 vehicles. You can’t just follow government driving compliance standards…?”

Third, given that (1) encryption isn’t a proper solution to the loss of credentials and (2) those in charge at the time of a breach sometimes spin blame onto those who try to guide them, do I agree with a Governor’s demand that encryption be added to regulation?

Actually, yes.

I’m obviously pro-regulation for a number of reasons but as I’ve stated for years encryption is neither difficult nor costly to implement properly. The reasons not to encrypt are fast disappearing, which begs the question of why the Governor wasn’t already adopting it. Why did she think she had to wait for regulation by the federal government before she could act?

In 2005 I presented at a conference to card brands and retailers a solution that would allow end-to-end encryption of their customer data.

Although we made great technical progress I will never forget the words of a CFO who reviewed our proposal: “Davi, we don’t want to be bleeding edge.” That used to be a typical reaction eight years ago and one of the reasons I set out to present to people around the world how to do encryption.

Most recently I ran into this sort of reaction in China, but it seems to have started to wane in America. More and more demand for encryption is starting and regulators have already written it into state laws (e.g. Nevada’s 2009 law SB 227 and Massachusetts’ 2009 law 201 CMR 17).

And while some states have moved towards explicit encryption, others have implied or suggested encryption laws. Notice, for example, that the 2009 South Carolina breach law offers an encryption safe-harbor clause:

Definition of Personal Information: The first name or first initial and last name in combination with and linked to any one or more of the following data elements that relate to a resident of this State, when the data elements are neither encrypted nor redacted

We can thank California’s 2003 SB 1386 for the rise in breach laws and encryption clauses over the past nine years but actually we can thank Heartland for most of the mindset shift after 2008 (more than just coincidence with the timing of encryption laws). In other words, I also will never forget (five years after my presentation on end-to-end encryption for PCI) the CEO of Heartland asking why no one had forced him to spend money on end-to-end encryption.

Heartland Payment Systems, the victim last year of a massive data breach of sensitive card data, vowed after that devastating event to develop new security gear based on end-to-end encryption between itself and its merchants to prevent such a breach from occurring again. That’s now taking shape, but slowly.

The fact was no matter how I characterized encryption in terms of a long history of deployment and use (don’t get me started on the Roman empire) if the regulators did not demand it now, there were always some executives I consulted with who said they didn’t see the “pressure” to do it. There were those who wanted encryption to be so far behind their adoption curve that they could hold up a requirement to prove to their constituents that it was necessary (e.g. low risk to them).

So yes, I think regulators should force South Carolina’s Governor to adopt the aging encryption controls because, as with Heartland, some leaders haven’t been able to take that step before a breach hits the fan. I also think regulators should demand South Carolina’s Governor explain how she will use encryption to protect data if keys to encryption have been stolen (e.g. as described in her incident report).

And try not to look suprised when she asks “What do the requirements say…?”


Updated to add: The IRS apparently has responded with a statement that encryption is required, as reported by WMBF news.

The governor says she’s meeting with the state’s congressmen to have the IRS require encryption in its standards. But the IRS says that’s already on the books.

Unfortunately WMBF has a vague and diplomatic quote from the IRS — no specific requirement is cited.

We have many different systems with a variety of safeguards — including encryption — to protect taxpayer data. The IRS has in a place a robust cyber security of technology, people and processes to monitor IRS systems and networks.

We work closely with the states to ensure the protection of federal tax data. We have a long list of requirements for states to handle and protect federal tax information.

Aptitude kept back on Ubuntu 12.04

The occaisonal Ubuntu quirks continue. I’ve received a lot of positive feedback and hits on my other fix posts, and the amazing Nate Lawson said I should keep doing them, so here’s another quickie.

I found aptitude failing updates in the GUI (Update Manager) patch cycle, so I switched into terminal to read the output and check what’s what.

user@system:~$ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages have been kept back:
  aptitude
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
user@system:

The failed package is clearly only “aptitude”. More info can be gleaned by looking at the install error for just that package.

user@system:~$ sudo apt-get install aptitude

That command made the system complain about dependency in libapt-pkg4.12.

I checked the update status for libapt-pkg4.12.

The update site showed “Latest version: 0.8.16~exp12ubuntu10.5” from 2012-10-24 18:06:55 UTC. I then checked my system and I still had 0.8.16~exp12ubuntu10.2 (2012-06-15 23:06:45 UTC). Not good. Fortunately I could see 10.2 was the latest security update (CVE-2012-0954 CVSS v2 Base Score:2.6) but the expectation of 10.5 was causing the update error.

Proceed at your own risk but this was the straightforward fix.

  1. Download the latest package, based on architecture:
    wget http://security.ubuntu.com/ubuntu/pool/main/a/apt/libapt-pkg4.12_0.8.16~exp12ubuntu10.5_amd64.deb
  2. Force removal of old package:
    sudo dpkg --force-depends -r libapt-pkg4.12
  3. Install new package you just downloaded in step 1:
    sudo dpkg -i libapt-pkg4.12_0.8.16~exp12ubuntu10.5_amd64.deb

    This can be verified in /var/log/dpkg.log: “status installed libapt-pkg4.12 0.8.16~exp12ubuntu10.5”

  4. Upgrade and see if all dependencies are met:
    sudo apt-get upgrade

It’s simple but annoying, especially on a LTS system.