Important information about Microsoft Meltdown CPU security fixes, antivirus vendors and you
Last week, Microsoft issued January’s cumulative security fixes for January 2018. Although the media focus has been around “Meltdown” and “Spectre” CPU fixes, these patches also include a range of important security fixes — including patches to SMB server.
These updates came with many caveats, and the Microsoft knowledge base articles have had extensive edits since publishing. There’s some really important things you should know before trying to apply the patches.
The main thing to know is the January patches, and currently all future security patches, will not install unless antivirus vendors take action — and some don’t want to or feel they cannot.
Microsoft require your Anti-Virus provider to certify compatibility
There is a problem where some anti-virus vendors are using techniques to bypass Kernel Patch Protection by injecting a hypervisor which they use to intercept syscalls and make assumptions about memory locations — memory locations which are now changing with the Meltdown fixes.
To be honest, some of the techniques are similar to ones used by rootkits — Kernel Patch Protection was introduced by Microsoft a decade ago to combat rootkits, in fact. Because some anti-virus vendors are using very questionable techniques they end up cause systems to ‘blue screen of death’ — aka get into reboot loops. This shouldn’t be possible in the latest operating systems, but some anti-virus vendors have managed it by taking themselves into the hypervisor — or “hardware assisted” as you’ll sometimes read in marketing material. Anti-Virus makers really shouldn’t be messing with systems like this.
In order to combat this Microsoft have requested Anti-Virus vendors to add a registry key every time they startup, to certify their product is working with the CPU fixes:
https://support.microsoft.com/en-us/help/4072699/january-3-2018-windows-security-updates-and-antivirus-software
You’ll find this bit very important:
“Customers will not receive the January 2018 security updates (or any subsequent security updates) and will not be protected from security vulnerabilities unless their antivirus software vendor sets the following registry key”
Until Anti-Virus makers add this registry key, you don’t get any security fixes.
Please note not only does this impact Windows Update, it also impacts Windows Server Update Services (WSUS) and System Center Configuration Manager (SCCM).
To remind you, if you don’t get this right — for example, your antivirus provider fails to set the key, your antivirus license has expired or antivirus is just broken on a PC, no more security updates will work and you “will not be protected from security vulnerabilities” in the words of Microsoft.
To make matters worse, in WSUS and SCCM, PCs and servers show the patches as Not Applicable/Not Required, making it look like systems are fully patched. They aren’t.
Tracking Anti-Virus vendors who have added the registry key
I have made a spreadsheet to track vendors who have complied, or not, with the instructions from Microsoft:
CVE-2017-5753, CVE-2017-5715, and CVE-2017-5754 (Meltdown and Spectre) Windows antivirus patch…
Patch tracking spreadsheet
You should look for vendors who are “Y, Y” — this means their products support the January 2018 security patch, and set the compatibility registry key.
In the case of some antivirus vendors, it has been a bumpy road. E.g. with Symantec Endpoint Protection, although engine updates now exist, Symantec recommend you don’t apply the Microsoft fixes at the time of writing:
Next Gen Endpoint providers aren’t applying the registry fix
This is the next problem. Next Gen Endpoint solution providers used to pitch themselves as an addition to antivirus software, an extra layer, but the last few months the major players have started to pitch as an antivirus replacement. Budgets are tight in IT departments — why not be the primary supplier, rather than the one you can’t afford, after all?
Except they aren’t setting the registry key for compatibility — almost all of them claim because they don’t want to risk blue screening a system, in case the customer also has other antivirus software installed.
Here’s Palo-Alto as an example:
Their support article for this (customers only) says:
So if you use Palo-Alto to replace your legacy antivirus, congrats, you won’t be protected from security vulnerabilities on your endpoint unless you manually create the registry key antivirus vendors are supposed to create. Palo-Alto are a member of Microsoft MAPP, and have seen the requirements.
Since TRAPS protects you from known and unknown exploits you might think you are protected from Meltdown, but.. well..
Palo-Alto aren’t alone. For example, Cylance with CylancePROTECT now boast — including in sales pitches and on their website — they can now replace antivirus.
However, Cylance too don’t automatically set the registry key.
These two examples are common across the ‘next gen’ vendors I’ve checked out, they simply don’t feel able to set the registry key, which can create this customer journey:
Buy a next gen security product to replace antivirus and detect unknown exploits and malware.
No longer receive any Microsoft security updates.
Not be able to detect Meltdown exploit.
Have to manually frig a registry entry or deploy a .exe to set a registry key to get updates working again.
That isn’t optimal.
Call to antivirus vendors
Please stop using goofy, undocumented and hacky ways to predict memory locations and mess with syscalls. There’s 5 key vendors doing this (and lots of OEM vendors licensing engines): please tidy up the code.
Call to next gen antivirus vendors
If you’re selling yourself as an antivirus replacement, and you’re in the Microsoft MAPP programme, you need to be able to live as an antivirus vendor.
Call to Microsoft
The compatibility registry key exists for a reason. I know. I can also see it’s a messy hacky fix. But it needs an end of life date — this is going to decrease security for everybody in the long term, as trust me, antivirus will be broken on some PCs in some Enterprises and homes, and so they won’t be getting security updates. In short, the registry key check is going to need to have a drop dead date set (and, yes, antivirus vendors doing silly things to bypass KPP are going to have to take the heat).
There is also another element here — on Windows Server, the Meltdown and Spectre patches don’t actually do a thing.
Here’s a diagram I made of how enabling is handled:
The Microsoft guide here is:
https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution
Here’s the guidance:
To enable the fix
reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management” /v FeatureSettingsOverride /t REG_DWORD /d 0 /f
reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management” /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f
reg add “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization” /v MinVmVersionForCpuBasedMitigations /t REG_SZ /d “1.0” /f
If this is a Hyper-V host: fully shutdown all Virtual Machines.
Restart the server for changes to take effect.
So yes, unless you actually add those keys the patches don’t actually enable the CPU mitigations.
And if you do, keep in mind:
Wrapping up, this has been incredibly messy for everybody involved. My belief is organisations shouldn’t rush these patches out. They need to carefully test and see where they need to mitigate the vulnerability. The vulnerability only exists if you can run code on the device. The Meltdown and Spectre vulnerabilities are “information disclosure”, which means you need code execution to read memory. So — to give an example — if you’re worried about somebody owning your Active Directory or SQL Server, to attack with this vulnerability they would already need access to your Active Directory or SQL Server to run code. If they can run code, it’s already game over.
This isn’t as black and white as the world is melting. Organisations need to carefully assess and manage their situation.
It’s also my first month ever as a security vulnerability manager at my new job. Hello. It has been an interesting week.
~k