Tuesday 18 November 2014

MS14-066: To Patch or Not to Patch?

Note: Since I originally posted this, Microsoft have updated the MS14-066 patch, which they say now resolves the issues the original patch caused.

A week ago (11th November 2014) Microsoft released a patch for of the one most critical Microsoft vulnerabilities seen in a long time – MS14-066. The vulnerability is in the Schannel (Microsoft Secure Channel) component, which is present in pretty much every version of Microsoft Windows, including the unsupported Windows XP and NT. The vulnerability may allow remote code execution by an attacker, but what makes this vulnerability stand out as a particularly more serious than the typical Microsoft remote code execution vulnerabilities, is it can be exploited directly via a network connection, and there is nothing which can be done to mitigate it, other than switching off or network disconnecting your Windows system.

Microsoft Windows servers and services that have direct Internet connectivity pose the highest risk, whether they be ISS web servers or VPN services, unpatched against MS14-066, they are at high risk of exploitation. But that is not to say users of Windows OS on desktops and laptops are not at serious risk as well.

Therefore it should be a complete ‘no brainer’ for business to quickly apply the MS14-066 patch, but a curveball has been thrown, in that there has been reports of server issues occurring after applying the patch, specifically with TLS 1.2 causing services to hang or to disconnect. Microsoft have published a work around for this issue, which involves deleting the following ciphers from the registry, a simple enough fix.

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256

So to the question I have been asked quite a bit this week, should this patch be applied now or should we wait until Microsoft release a more reliable patch?

Well firstly a golden rule of patching critical servers is to test the patch first, as patching always carries a risk of impacting the availability of services and breaking applications. The TLS 1.2 issue is straightforward to test for and simple enough to resolve if found to be a problem in testing.

Another golden rule of patching is to have a back-out plan, any patch carries a risk of breaking systems and applications, even with testing, so there should always be written plan to roll back critical systems should a patch cause an issue.

The ‘whether to patch now’ question becomes even more clear-cut when you consider it this way; with this vulnerability remaining present (unpatched), it means there is a significant risk for the compromise of confidentiality & integrity, whereas applying the patch carries a risk of losing server/service availability. 

High Risk of Confidentiality Compromise (unpatched) Vs Low Risk of Availability (patched)

Availability rarely trumps confidentiality in InfoSec, and in my view it certainly doesn’t in this scenario when weighing up the risk of not applying the patch, remember there is nothing that can be done to mitigate the risk of an unpatched system, other than applying the patch.

Therefore my conclusion is to quickly apply the patch to all Windows OS, testing for TLS 1.2 issue with any critical systems, and to start with patching all Microsoft OS Internet facing services first.