Microsoft disables Windows Update when Meltdown/Spectre registry key isn't set
doublepulsar.com
doublepulsar.com
I had to dig around to find a page [2] that had some useful instructions allowing me to find out what the actual status of my Windows install was. I'm grateful to the author of that page, they provided critical info that neither Microsoft nor my machine's manufacturer did. I wish I could say that it boggles my mind that they could be so hushmouthed on the subject of a vulnerability this severe. Of course, my OEM (Lenovo) has not released an update for my Windows laptop (Yoga 900) since 2016, and as of today their support page [3] on Meltdown/Spectre does not indicate that they plan to do so.
I'm posting this partly in anger/despair, partly in the hope that I'm wrong and that someone will pop up to comment and tell me there's a fix. There is a Linux BIOS for this machine but it's old and I don't know if it will actually address this issue.
[1] https://support.microsoft.com/en-us/help/4056892/windows-10-... [2] https://www.bleepingcomputer.com/news/security/list-of-meltd... [3] https://support.lenovo.com/us/en/solutions/len-18282
>... if your system firmware is not ready to accept the update, Windows Update will not apply it, and _it won't tell you_ that it's not applying it -- it will simply say 'Your device is up to date'.
The update enables mitigations for Meltdown regardless of firmware.
You need updated firmware for updated CPU microcode to mitigate Spectre.
>I had to dig around to find a page [2] that had some useful instructions allowing me to find out what the actual status of my Windows install was.
All this is transparently revealed when you run `Get-SpeculationControlSettings`, which is mentioned in the update guidelines, eg https://support.microsoft.com/en-us/help/4073119/
Does that mean I'll just be left out cold? That's how I understand it.
When I run the Microsoft Powershell plugin that they made available to check the protection status (`Get-SpeculationControlSettings`) I get a "True" for 3 of 8 items (only showing those 3):
Windows OS support for branch target injection mitigation is present: True
Windows OS support for kernel VA shadow is present: True
Windows OS support for kernel VA shadow is enabled: TrueContacted Dell support and confirmed they will not be releasing a BIOS update for the system.
First harm to me from this issue. Not sure if it means I will have to join a class action against Dell or Intel
http://www.dell.com/support/article/us/en/19/sln308587/micro...
This link helps clarify the steps needed. https://doublepulsar.com/important-information-about-microso...
Pay specific attention to the dataflow. Registry keys have to be set in a certain order in order for a) the patch to download and install and b) actually enable.
If there is not a BIOS fix (I'm in the same boat as you), the other hope is that the OS or virtualization provider includes CPU microcode in their update to address this.
At this time, I do not believe Microsoft has included microcode in their current update. However, they do have the capability so that's something you can ask them about doing so at some point.
but sadly no mention of what Windows users are supposed to do.
My Windows systems are VMs so I updated to the latest ESXI release (as of yesterday) which includes microcode. See https://www.vmware.com/us/security/advisories/VMSA-2018-0004...
Another incentive to stop using questionable AV software (since this was implemented because they can't get their act together).
there was a list posted yesterday on compatibility that is continued to be updated: https://docs.google.com/spreadsheets/d/184wcDt9I9TUNFFbsAVLp...
If you haven't installed dodgy third-party AV, you're fine.
Unfortunately I have no reason to use it, though. I don't even know whether it's any good. But at least I know it's not dodgy!
I don't think its ready to be run on Windows boxes unless you are a power user willing to manually verify ~100 files are not actually malware.
It is because these (misbehaved) 3rd party applications do things that cause the mitigations update to make computers unusable.
>and of all things, hilariously defaulting to 'no'
It does not default to "no" since the default is to run MSE / Defender.
> It does not default to "no" since the default is to run MSE / Defender.
I think that it's reasonable to read the grandparent's post as meaning "defaulting to 'no' under certain conditions on the system". It would surprise me if there weren't plenty of users out there who have legacy workflows with antiquated antivirus software still running, either because they set it up and haven't changed it or because their local tech geeks set it up and they don't know how to change it. I know that, as I've tried gradually (and unsuccessfully) to ease back into Windows after a long time away, it's been hard for me to believe in Defender as a full AV solution, and my first instinct was to run old favourites like ClamAV as an extra layer of defence.
(Of course, let's ignore the obvious joke about some AV solutions like Symantec.)
Difficult situation for Microsoft. If you install applications which mess with the operating system in unsupported ways you can't expect your system to function correctly with automatic updates. On the other hand, users are likely not aware of what they have done and bricking millions of computers is also not good. Might for example cause a backslash when people stop updating their systems.
This sounds like a quick and dirty fix they put in place while figuring out what to do.
They have reasons for doing it the other way, but I definitely blame them for not standing up to crap AV vendors in this and many other situations.
That seems like a crazy thought process. You're running software that modifies Window's internal functionality. The vendor knows it's unsupported. How can you blame the company who just made the platform you compromised?
Might as well set your root password to "password" and open it to the public then complain that the security is bad.
Yes it is.
AV use various hacks and exploits to hijack calls to the kernel. How did you think they notify you of an infected file before you open the infected file? The AV intercepts kernel API calls to list and open files.
I wouldn't be surprised if the patch for meltdown/spectre breaks these techniques. Generally speaking, these techniques will crash the system if they didn't work as intended. Microsoft doesn't want AV to BSOD millions of computers so they don't update when they detect an AV. It's perfectly reasonable to me.
So, again, the "where do you want to go today?" company decides "never mind, this is where you are going: we're stopping updates because you might have thought about it."
It has been first-party for many years - MSE was released 2009-09 per Wikipedia.
In the PC case both Windows and AV are third party products.
Coping with Windows is a fact of life. Get used to it.
Plenty of us have gotten rid of that virus years ago; yes even at work.
echoes from 1998.
http://www.catb.org/~esr/halloween/
Your use of the word 'coping' is telling.
p.s. I can't remember the last time I touched MS software outside of a VM.
The default is to use the 1st party product, Windows Defender, which defaults to 'yes'.
It works well, they are actively developing it, and the new white list based directory protection is kinda neat if you're scared of ransomware.
I couldn't agree more. As I've been devising a patching plan over the past few days I couldn't help but wonder "how long will I have to do this"? My hope is that in future OS releases (say, Windows Client/Server 1803) the mitigations will be default-on for clean installations (minimally).
[0]https://docs.google.com/spreadsheets/d/184wcDt9I9TUNFFbsAVLp...
[1]: https://blogs.technet.microsoft.com/ash/2016/03/02/windows-1...
However I was able to install the security update manually from the Microsoft Windows update catalog download site. I did this after enabling defender briefly and updating it to ensure that the registry key was written.
The machine was slicing up 11 channels of 24fps videos into jpegs, so 264 jpegs/s at 720p and 24 bit color.
I've had friends and coworkers that have hit the same CPU issues with big git repos and defender.
It seems like Defender has problems with getting hit with tons of small files in quick succession, but really I know very little about it.
(I don't care, an update took down the sound last year. For all I know the next one will make the gizmo totally malfunction ... MS don't care for that cheapo segment either, the wanton demands for disk space are astounding, and they refuse to use their own exFat format on additional storage. Truly ready to ascend to Oracle level, they are.)
Seriously? An OS of which you need an obscure, hard-to-get version, special messing around in power tools, and still might break randomly? This role reversal happening in the last 10 years is sad, really.
Still, could have been better communicated.
https://www.pcworld.com/article/3020327/antivirus-software-c...
Consider CVE-2017-0290[0], which was caused by the MsMpEng process running a custom unsandboxed javascript interpreter with system privileges to evaluate untrusted code for maliciousness. Remotely exploitable over many unsolicited channels. Pretty much the worst kind of exploitability. Of course other AVs have done quite similar mistakes.
[0] https://bugs.chromium.org/p/project-zero/issues/detail?id=12...
I must have upset the hive mind by sharing a link. Oh well, hopefully someone finds value here.
3rd party AV generally has better hit rates and the good ones are dramatically less demanding of system resources (happy with NOD32 here)