There are updates to Flash 15, the leading-edge version for Windows and OS X; to Flash 13, Adobe’s Extended Support Release for those who like life a bit behind the front of the wave; and for Flash 11, the stuck-in-the-past version that is the most recent one available on Linux.
As usual, Adobe’s own bulletin is big on the list of version numbers but thin on detail.
However, there are 18 CVEs patched, including Remote Code Execution (RCE) bugs.
Where web-based content is concerned, RCEs are often more descriptively called “click-to-own,” because simply clicking through to a page containing a dodgy Flash item could leave you infected.
As usual, our Flash advice is:
- If you have Flash Player, don’t wait to apply the update, because of the click-to-own risks.
- Enable “click to play” if your browser supports it, so Flash only runs when you really want it to.
- Unless you are certain you need it, try uninstalling Flash altogether and see if you can live without it.
If you prefer to update Flash by manually by installing the new version over the old, don’t forget that you can use Adobe’s so-called Distribution page to download a standalone installer.
(Be sure to read the FAQ first to ensure you are aware of any licensing niceties.)
The standalone installer can be used offline and is self-contained, so it doesn’t try to push you into installing so-called foistware – third-party software you didn’t set out to find, but are nevertheless squeezed towards trying out.
Microsoft, in contrast, pre-announced 16 different security bulletins this month.
However, two of them fell by the wayside, leaving us with 14 updates, of which 5 could lead to RCE, with 4 deemed critical.
Usually, when one of Redmond’s updates slips, the bulletins that would have been below it in numeric order all move up a spot so there are no gaps in the numbered list.
That didn’t happen this time, with MS14-068 and MS14-075 denoted simply, “Release date to be determined.”
The big one
Of the RCE bugs that were patched, one is likely to get a lot more attention than the others, simply because of its locus.
It hasn’t picked up a media-savvy name yet.
Let’s hope, because it was privately reported, that no-one with a penchant for trendy bug naming yet knows how, or even if, MS14-066 can reliably be exploited.
This is a vulnerability in Secure Channel, also known as Schannel.
Indeed, as Dan Goodin over at Ars Technica drily wrote, this now means “that every major TLS stack has had a severe vulnerability this year.”
If you have a Windows server or client application that uses TLS, for example to support HTTPS, it’s highly likely that you are making use of Schannel.
As Microsoft’s advisory points out, “The vulnerability could allow remote code execution if an attacker sends specially crafted packets to a Windows server,” concluding that “[t]his security update is rated Critical for all supported releases of Microsoft Windows.”
Critical is the word – and that doesn’t just mean critical for servers on which you are officially running IIS, but even for your Server Core installs.
The silver lining in MS14-066 (and who can blame Microsoft for mentioning this detail in the advisory text!) is that the update adds in four new TLS cipher suites, giving you support for Galois/Counter Mode (GCM), with and without forward secrecy.
Forward secrecy is a desirable extra layer of public-private encryption that means even if a crook steals your whole server and all its encryption keys, old messages can’t be decrypted.
Other RCE holes
Other software components at risk of remote exploitation include:
- Microsoft’s XML subsystem, patched in MS14-067, which could be attacked by malicious content in a web page.
- Microsoft Office, patched in MS14-069, which could be at risk of an “open-and-own” attack caused by a poisoned document on a web page or in an email.
- Object Linking and Embedding (OLE), patched in MS14-064.
Sandworm attacks have been seen in limited numbers in the wild: a crook sends you a PowerPoint file that contains an embedded EXE file (i.e. a program) disguised as a GIF image, plus an INF file (a sort of setup script).
Neither file ought to be able to cause any harm, but a bug in how Windows handles OLE encoding means that the INF file gets “executed”.
The INF can’t run the bogus GIF file directly, but it can move it into harm’s way and set a registry entry so it runs next time you logon.
There’s also a longish list of Elevation of Privilege (EoP) bugs, flaws which allow an attacker who has already snuck into your network to award himself administrator privileges.
EoPs can turn a regrettable but manageable intrusion into a disastrous compromise.
Many attackers (and penetration testers) like to deploy their exploits in pairs: an RCE to get in, and an EoP to go up.
The kernel hole that wasn’t
Last on Microsoft’s list for November 2014 is a bug that sounds as though it could have been much worse.
MS14-079 only clocks up a Moderate rating, even though it is a vulnerability in font rendering in the kernel itself.
These days, fonts are often (and unexceptionably) embedded in web pages, just like images.
So an RCE bug in the Windows font system – which is still rather controversially embedded in the kernel for performance reasons – could give an attacker control over every aspect of the infected computer.
In this case, however, it looks as though the bug can only be used to provoke a Denial of Service (DoS), rather than a full-blown RCE.
Still, a kernel-level DoS often shows up as a Blue Screen of Death, not merely sluggishness in performance or a stalled service.
The bottom line
We’ll say what we always do: patch early, patch often.
In particular, MS14-064 (the patch to the Sandworm patch) deals with an attack already seen in the wild, albeit only on a limited scale; and MS14-066 deals with a potential security hole in Microsoft’s Secure Channel software itself.
Either of those updates on its own would a good reason to get patching right away.