Skip to main content

Post-Patch Tuesday Roundup: May 2020

Post-Patch Tuesday Roundup: May 2020

Networking & security

security patch blog 01 (002)

Tim Lovegrove

Security Analyst

Welcome back to another instalment of the Softcat Post-Patch Tuesday roundup. With lockdown still in effect, admins face an ongoing challenge to manage both their remote user devices and their on-premise server estate, and this month there’s quite a range of updates to get to grips with. There’s a lot to cover outside of the usual Microsoft releases, so let’s get started…


Another large drop from Microsoft this month, with 111 updates included in the monthly Cumulative Update. These cover a familiar spread of components across the Windows ecosystem, and the good news is that none of them are known to be being targeted in the wild. As we know though, Patch Tuesday is also followed closely by malicious actors looking for new attack vectors, and new methods are quickly developed after the patches are released and reverse engineered.

Possibly the most notable updates this month are CVE-2020-1126, affecting the Windows Media Foundation and CVE-2020-1117 affecting the Color Management Module. These core Windows components are involved in many aspects of content delivery in the OS, with the Media Foundation covering audio and video rendering in a multitude of applications, including web browsers, and Color Management being responsible for aspects of display rendering. The vulnerabilities are memory corruption issues which can enable an attacker to install programs, modify data or create user accounts on the victim machine simply by visiting a malicious website.

CVE-2020-1118 affects TLS, specifically the way Windows handles certain key exchanges. Rather than compromising encryption itself, this actually causes a denial of service by triggering an automatic reboot of the system, which could be exploited to cause ongoing system outages.

We’ve also had our attention drawn back to CVE-2020-0688, a serious Exchange vulnerability reported in February 2020 that can result in complete takeover of the system, including the underlying Active Directory, via stolen mailbox creds. Our friends at Rapid7 have released research that shows a large number of vulnerable or potentially vulnerable systems are still present and available over the internet.

This appears to be a symptom of the widespread practice of updating server applications more slowly than their host OSes. Server applications (Exchange, SQL, SharePoint etc) tend to have a longer service window, with quarterly service packs or update roll-ups being common and admins often choose to wait several months after their release for them to be proved stable before deploying these updates. This means vulnerabilities can be present in a system for 4, 5 or even 6 months before being addressed, plenty of time for attacks to be targeted at them. The longer service cycle doesn’t remove the need for a fast response to critical updates, especially where systems are internet-facing.


Short and sweet from Adobe this month – updates for Acrobat and Reader, plus the DNG Software Development Kit.


Cisco have dropped a large number of updates for a variety of products in May, primarily focussed around ASA and Firepower/FTD security appliances. Many of these receive Cisco’s High impact rating, their second most serious rating, and it’s the accumulation of many of these vulnerabilities, rather than any one super-high-rated vulnerability, that makes it important to update the devices: the presence of many lower-rated vulns provide an attacker with an array of options. As with server applications, it’s common to delay updating perimeter and networking devices to ensure stability, but network admins should keep an eye on the available patches and apply them accordingly.


We have a confession to make: we missed CVE-2020-3952 last month. This critical vuln scores a perfect 10 and affects VMWare’s vCenter management tool. vCenter can be deployed either on a Windows server or as a Linux-based virtual appliance, and one component of this is the Platform Services Controller (PSC), responsible for centralizing license management, SSO authentication and several other services. The PSC can also be deployed either as part of the vCenter deployment or separately, and this vulnerability allows an attacker to extract information, including credentials, from the vmdir directory service over port 389. This in turn can be used to compromise the vCenter server and take over the virtual estate.

This all sounds terrible, and certainly is, however the caveat is that the attacker must be able to reach the PSC over the network in order to carry out the attack. This is good news – the virtual infrastructure surrounding vCenter, the PSC and other components is typically segregated away from the main network, and often is further zoned or firewalled away from even the regular backoffice estate. This makes it hard for an attacker to get access – as we often say, if they can get to it, you already have some massive problems going on elsewhere.