Sophos Cloud Optix
Adobe
Adobe’s monthly security update rollcall for November 2014 is limited to the Flash Player product.
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
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.
Loosely put, Schannel is to Windows what Network Security Services (NSS) is to Firefox; what Secure Transport is to Apple; or what OpenSSL is to a vast swathe of the open source world.
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.
GCM is a handy cipher that combines encryption and authentication, so you can’t make exploitable mistakes in doing those two steps separately yourself.
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.
The OLE bug patched in November 2014 looks as though it is a variant of the Sandworm hole that was patched incompletely in October 2014.
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.
Patchwork letters and background of denim cloth courtesy of Shutterstock.
Windows Central is reporting that Microsoft just patched a Windows exploit that had existed for 19 years, any of you guys at Sophos know anymore on this.
Seems to be one of the privately disclosed holes fixed in the usual Cumulative Update to Internet Explorer.
Not being from IBM, who are the people who supposedly found it, I wasn’t aware of that detail (i.e. that it was 19 years old).
Interesting; intriguing, perhaps. Possibly even important. Bugs can last a l-o-n-g time before anyone notices.
Not sure what else to say. “Better late than never,” perhaps?
It was foolish to include the new ciphersuites in the update for MS14-066.
Now an attacker can very easily determine if a host has a patched TLS implementation or not from passive observation of TLS session handshakes.
As part of the TLS session establishment, the client sends a list of all the ciphersuites it supports, in clear text. (Obviously it must be cleartext, as the secure channel parameters are not yet established).
An attacker with this level of visibility could then pop the client by replacing the server cert in the subsequent Certificate message from the Server; or otherwise introduce the crafted cert to the client another way (S/MIME in Outlook as a vector comes to mind – has been exploited in the past).
I hear you, but by that argument, most patches are “dangerous” because an attacker can often differentiate between an unpatched and a patched computer by the behavioural changes wrought by the patch.
Seems to me like an attacker with your level of visibility (and with a working exploit) could differentiate between patched and unpatched computers simply by trying the exploit. If it works, guess what? The computer was unpatched 🙂 (OK, my way is noisier because the attacker will end up probing systems that are immune as well as vulnerable, generating more traffic…but if you’ve got a way to spot an attack against already-patched computer, why not use it to spot and block attacks against your unpatched computers at the same time?)
“servers on which you are officially running ISS”
I didn’t realise you could run the International Space Station on a Windows server! :o)
(I think you meant “IIS”.)
I think you are right. (Either that or I meant to say “servers which you are officially running on ISS.”)
Fixed, thanks.
I’m a teacher, so I thought Microsoft was now offering In School Suspension services…
For unfortunates running EMET 5.0 on W7 the patches of Tuesday would also have caused IE11 to refuse to run. Solution is to uninstall, then install EMET 5.1 which, believe it or not, was only released on Monday. Not clever.