Patch Tuesday for June 2014 – 7 bulletins, 3 RCEs, 2 critical, and 1 funky sort of hole

The elevator pitch for this month’s Microsoft Patch Tuesday is as follows:

• Seven bulletins.
• Three remote code execution (RCE) holes, of which two are deemed Critical.
• Patches apply to Windows, Internet Explorer (IE), Office, Live Meeting and Lync.
• All supported versions of IE get patches.
• All Windows versions, including Server Core and RT, get at least one Critical RCE patch.
• All patched systems need a reboot.

Even more briefly: you’ll need to patch and reboot every Windows system on your network.

OK, except for your Windows XP computers.

But why not reboot them all in solidarity, anyway?

Some of them might not come back up, and then you’ll have an excuse to tell your boss that you can’t put off updating them any more.

An unusual patch

One of the patches, number seven, is a security hole of a type you don’t see announced very often in Microsoft bulletins: Tampering.

You’re probably used to seeing vulnerability tags like RCE (remote code execution), EoP (elevation of privilege, where a regular user can get unauthorised administrative or system powers), DoS (denial of service, where an outsider can crash software that you rely on), and Information Disclosure (where data that should stay private can be accessed without authorisation).

If you’ve listened to our Understanding Vulnerabilities podcast, you’ll know that RCE bugs usually get the most attention, because they offer a break-and-enter path to attackers who are outside your network.

But the other sorts of vulnerability can be combined with RCE into a much more dangerous cocktail.

For example, a Disclosure bug might allow crooks to steal authentication data that makes it much easier for them to pull off an RCE; a cunningly timed DoS might knock out intrusion detection software that would otherwise trigger an alert; and an EoP might add system administrator powers to a user-level compromise.

→ Here’s an analogy: a Disclosure bug tells a crook where you live and when you won’t be home; the RCE lets him pick your front door lock and get inside; the DoS means he knows how to turn off your burglar alarm; and the EoP gets him into your safe as well, once he’s in the house.

Tampering explained

Tampering is another sort of security hole that may help crooks, either by allowing them to initiate their attack more easily, or by making things worse for you once they have broken in.

Very loosely, tampering means that you can make a security-related change that should raise an alarm, but doesn’t.

For example, you might be able to add malware to someone else’s digitally signed software and have the system still accept it as trusted.

You might be able to make your own digital certificate, for example for a fake web page, but pass it off as someone else’s.

Or you might be able to tamper with a protected configuration file, thus altering the settings and behaviour of software such as a web server, without being noticed.

One well-known example of a tampering exploit is last year’s MasterKey malware for Android, which bypassed Google’s Android Package (APK) cryptographic verifier, making the malware look legitimate.

This didn’t just allow the malware to get the blessing of Google’s compulsory install-time security check, but also allowed the crooks to put the blame on a innocent vendor, whose digitally signed package they started with.

Another famous tampering exploit is the announcement by security researchers in 2008 that they had succeeded in creating a fake Certification Authority web certificate by finding a collision in the MD5 hashing algorithm.

Their home-made certificate appeared to have been signed by one of the top-level “root authorities” that almost every browser trusts by default, and would have allowed them to sign apparently-trusted certificates for any website they liked.

→ Don’t use MD5 in any new project. We knew it was cryptographically flawed before 2008, but the abovementioned certificate crack made it quite clear that it was dangerously unsafe in real life, not just in the lab.

We can’t yet say exactly what form this latest Windows tampering vulnerability takes, but it affects Windows 7; 8 and 8.1; Server 2008 R2 (not Itanium, and not Server Core); and all supported flavours of Server 2012, including Server Core.

Watch this space: we’ll tell you more after we’ve spoken officially to Microsoft on Patch Tuesday itself.

Theoretical zero-day fixed

The final item of interest about the June 2014 Patch Tuesday is that the update to IE fixes a security hole known as CVE-2014-1770.

Technically, this became a zero-day in IE 8 when it was disclosed by HP’s Zero Day Initiative during May 2014, after Microsoft hadn’t managed to come up with a fix for six months. (More precisely, after 180 days.)

The discoverer of the bug, who sold it to HP for an undisclosed sum, was careful to point out that all that was published last month was an advisory, not a proof of concept; indeed, he said that “it won’t be easy reproduce the vulnerability based on the advisory alone.”

Even after you have uncovered a vulnerability, there is almost always a lot of work (and sometimes it proves as good as impossible) to weaponise the vulnerability by actually coming up with a way to exploit it.

According to Microsoft, writing on its Security Response Center blog, no in-the-wild exploit using CVE-2014-1770 was ever seen, and thankfully the issue becomes moot on 10 June 2014, when the latest IE patches come out.

The bottom line

As we said at the outset: you’ll need to patch and reboot every Windows system on your network this month.

Except XP, but that’s another can of worms altogether.

Have a happy Tuesday!