Meltdown and Spectre: What you need to know!
Here we are at the start of 2018 with a significant security issue that has a known resolution ready to go. Sound familiar? Well it probably should because we started 2017 pretty much the same way. As you might recall, the Shadow Brokers had disclosed the SMB exploits that later led to many global cyber security events.
The CPU vulnerabilities known as Meltdown (Intel only) and Spectre (Intel, AMD, and ARM) were discovered by several independent researchers using multiple proof-of-concept examples of the attack methods. They stole credentials in real time and did other interesting things like allowing a user mode process in a VM environment to gain access to other data being processed on the same physical hardware. For some light reading on the issues please see the following list.
- CERT Vulnerability Note VU#584653
- Intel Security Advisory (Intel-SA-00088)
- Microsoft Security Advisory (ADV180002)
There have been several days of headlines, write-ups, PoC posts, and more on what the issues are. I want to focus more on the actions everyone should be taking and share a few of the write-ups on that. All the advisories outlined above give the same basic guidance:
- Apply operating system updates (some application updates mitigate these attacks as well)
- On Windows servers you need to enable the mitigation features and reboot the system again for them to take effect
- Apply firmware updates
Microsoft Guidance to Protect Against Speculative Execution Side-Channel Vulnerabilities (includes PowerShell examples on how to test to ensure a Windows system is properly protected)
What is affected?
If you looked at the CERT KB you would have seen the list of affected vendors, which was pretty much everyone. Microsoft released updates for all supported Windows operating systems late last week. Apple released updates for OSX 10.13.2 and was working on 10.13.3, then reportedly would start working back from there. Several Linux distros have also released kernel updates. Intel released updates for CPUs dating back five years (the issue affects CPUs going back more than two decades, so there is more to come). Many of the OEM vendors have started releasing updates for the newest and most common platforms and are working their way back.
There are a few known issues you will want to be aware of as you roll out fixes.
Possible performance impact: Many a troll out there has tried inflating the impact at a performance level when you apply the OS and firmware updates to resolve these vulnerabilities. The reality is yes, you may see a performance impact, but the results will vary. For the average user’s system, casual gamer, or systems with fewer user calls into the processor, the impact will not be that noticeable. On a system where there are far more calls crossing this boundary, like storage or network traffic, the impact may be much more noticeable. Expectations range from 5 to 30 percent. The reason for this is in how the fixes have been implemented. We are dealing with a fundamental hardware flaw that cannot be fixed physically, so the rules at a software and firmware level need to change to protect against this form of attack.
You are basically moving the conversation between user and CPU from a more face-to-face one to a shout to the next room, so to speak. If you are asking a quick question and get a quick response, you would not notice the impact in performance. As you try and have a longer conversation like a deeply intellectual or spiritual debate, you will find the tediousness of shouting into the next room adds up after a while.
There have been a few class-action suits filed, and one article I found even posted some metrics showing a 20 percent increase in CPU usage.
The impacts are going to be workload dependent, as both Intel and researchers from Google have attested to, so don’t expect all systems to be impacted significantly. But do test critical systems especially to validate what, if any, impacts you might see.
Incompatibility with AV may cause crashes\blue screen errors:
The Microsoft updates had some nasty conflicts with AV due to the changes to the kernel behavior and how many of the AV vendors were operating. AV vendors have been responding fairly quickly with updates to correct the issue; but to ensure its January OS patches install without a blue screen error, Microsoft has had to place an additional registry key to validate that systems have been updated (the AV running on the system is up-to-date) before their update systems will install the January patches. It was a good move on Microsoft’s part—a ton of blue-screened systems would have made a bad situation worse—and we at Ivanti implemented the same protection with our patching solutions. But it does leave a few edge cases to be concerned about:
- Systems that did not receive the update because the AV agent is in a disconnected environment, failing to update (it happens), etc. will not be able to install the Microsoft update through their update systems (WU, WSUS, SCCM, Ivanti, etc.).
- Systems NOT running AV will also not have the registry key and will not update. In this case you need to put the registry key in place manually or through some other means. This can be done through GPO or other means like our Custom Action example from Ivanti Patch for Windows.
**Update** Incompatibility with AMD processors could result in a unbootable scenario:
Reports of systems running on a small set of AMD processors becoming unbootable after the Operating System update has been applied have surfaced. Microsoft has implemented a preventative measure (likely just in Windows Updates only) to block install of these OS updates on AMD systems. Microsoft has stated in responses regarding the issue that the underlying problem was in documented behavior of AMD processors vs real world behavior. Microsoft intends to release additional changes to resolve these issues.
This leaves a few concerns out there. Do you have the visibility to know which systems have been updated or still need to be updated? Simply pushing the updates out may not be 100 percent reliable, so you need the reporting\analytics to be sure. Ivanti detection will show a missing update that is deployable for systems that meet the additional requirement, or a not deployable missing item that will stand out very clearly for systems that are vulnerable.
From a firmware perspective, we also have a number of options to assist you. Ivanti Endpoint Manager supports firmware updates as part of our UEM solution. Ivanti Patch for SCCM, our patching solution for SCCM environments, can pull in the major driver catalogs from Dell, HP, and Lenovo, so you can easily get access to the driver updates that have been made available and publish them to SCCM for distribution.
Home users, I haven’t forgotten about you. I personally used a tool from IO Bit called Driver Booster 5.1 Free. Installation was quick and easy, and the free version was able to update 19 drivers on my system. (Don’t judge! I do GPU updates religiously, but how often do you need to do a chipset, SATA, or HID device update?) I ran the supported detection tools mentioned above and verified all of my systems are good to go with both the OS and firmware updates in place. So I cranked up a little Fallout 4 and rid the commonwealth of a few more ghouls, super mutants, and raiders with nary a performance issue.
For more information on Ivanti Security Solutions, especially for patch management, check out our solutions page here.
For more details on these updates, the rest of the January Patch Tuesday updates that have already released, and those we are expecting on actual Patch Tuesday, you can catch all of our Patch Tuesday coverage on Ivanti’s Patch Tuesday page and our live webinar on Wednesday January 10th.
**Update** February 14th, Adding Ivanti Product related links for customer reference: