Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

1/29/2018
04:25 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

Microsoft Issues Emergency Patch to Disable Intel's Broken Spectre Fix

Affected Windows systems can also be set to "disable" or "enable" the Intel microcode update for Spectre attacks.

Fallout from flawed fixes for the Meltdown and Spectre microprocessor firmware vulnerabilities continues as Microsoft released a second emergency patch this month for Windows: this time, to deactivate Intel's buggy update for one of the Spectre issues.

Microsoft late Friday issued an out-of-band update that disables the mitigation patch for the branch target injection flaw (CVE-2017-5715), aka Spectre variant 2. Intel last week revealed that this firmware update caused spontaneous reboots and other system problems, and called for customers and OEMs to halt installation of patches for its Broadwell and Haswell microprocessors.

"Our own experience is that system instability like this may result in data loss or corruption," Microsoft said in a post for the new patch, which affects Windows 7 Service Pack 1, Windows 8.1, Windows 10, Windows Server 2008 R2 Standard, and Windows Server 2012 R2 Standard.

"While Intel tests, updates, and deploys new microcode, we are making available an out-of-band update today, KB4078130, that specifically disables only the mitigation against CVE-2017-5715," Microsoft said.

The good news in the update: Microsoft provides an option for "advanced users" to manually disable and enable the Spectre Variant 2 patch using registry-setting changes, which helps streamline the process. This allows them to "turn off" the flawed microcode fix via the Windows update rather than roll back the buggy patches. 

"This saves a lot of work. You don't have to uninstall the microcode update and restore to the previous version. You just set this flag and it ignores the microcode" patch, says Neil McDonald, vice president and distinguished analyst at Gartner.

The manual disable option is a good move by Microsoft, he says. "It's a way to just turn off the Variant 2" option, he says, giving them the choice to patch on the fly rather than the time-consuming process of rolling back the flawed patches.

"If there's an attack, they can reactivate it," he says.

McDonald says he hopes Microsoft provides the same strategy for Meltdown and Spectre Variant 1 vulnerability updates. That allows an organization to patch for the flaws based on performance tradeoffs since some environments can't sustain the slowdown. Instead, they can address the threat system by system, he says.

Microsoft recommends Windows users then reactivate the CVE 2017-5715 update after Intel gives the all-clear that it has fixed the performance problems it caused.

Jimmy Graham, director of product management at Qualys, notes that installing the emergency Microsoft patch should remedy system problems caused by the flawed update. "Installing this patch should return unstable systems to their former condition. This does mean that Spectre Variant 2 is not mitigated, but there are currently no active attacks against this vulnerability," Graham says. 

He says it's no surprise the microcode updates caused system problems because they aren't "typical software patches."

"They rely on microcode changes that directly impact how the processor functions. As with any patching, full testing of systems should be performed before production deployment. Especially in the case of Spectre and Meltdown patches, it is important to test these systems at production load to determine if there are any performance or stability concerns," Graham says.

Meantime, Intel CEO Brian Krzanich told analysts in the company's earnings call last week that Intel will unveil new products "later this year" that mitigate the Meltdown and Spectre vulnerabilities. "Our near-term focus is on delivering high-quality mitigations to protect our customers' infrastructure from these exploits. We're working to incorporate silicon-based changes to future products that will directly address the Spectre and Meltdown threats in hardware. And those products will begin appearing later this year," Krzanich said. 

But the Meltdown- and Spectre-free new microprocessors won't mean much to the current installed base of systems running on the vulnerable chips. While big cloud providers like Amazon, Microsoft, and Google may be able to update their systems in short order, most organizations realistically won't be able to do so. "For the typical organization, it will still be a multi-year journey," Gartner's McDonald says.

Related Content:

Kelly Jackson Higgins is the Executive Editor of Dark Reading. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
Page 1 / 2   >   >>
BrianN060
50%
50%
BrianN060,
User Rank: Ninja
1/29/2018 | 7:21:52 PM
A question for DR
Thanks Kelly,  Once we learned that underlying vulnerability was multi-chip-vendor (so multi-OS and Applications), we knew a long series of mitigation and fix iterations was inevitable. 

A question DR might be able to answer is: Would the last few weeks of chaos been avoided, if the confidentially informed vendors had more time before public disclosure? 
Kelly Jackson Higgins
50%
50%
Kelly Jackson Higgins,
User Rank: Strategist
1/30/2018 | 9:40:45 AM
Re: A question for DR
That's a great question, @BrianN060. I've wondered the same thing. The patches/updates were obviously rushed without time to properly vet and test them. The underlying (and well, ironic) problem of mitigating an attack against a performance feature in the microprocessor that ends up hurting performance is a tough one, for sure. The patches don't really fix anything--they just mitigate exploits--so I wonder how much more time it would have taken for Intel to come up with a more robust solution. The real fix to these flaws is a new generation of microprocessors, which will likely take years for most organizations to adopt. 

But overall, there indeed seems to have been a disconnect in the patch/update process among Intel and the system vendors. How are things going at your organization?
BrianN060
50%
50%
BrianN060,
User Rank: Ninja
1/30/2018 | 12:29:57 PM
Re: A question for DR
Thanks for asking, Kelly.  As a small consulting firm, it's pretty easy to keep an eye on things, and sidestep most chances for exploitation (especially the targeted, high-value attacks expected from M/S). Still, having to replace all effected devices won't be an easy pill for most small orgs and individuals.  I like the line from an 80s sitcom: "Great!  But can we afford it?"  "Sure.  It's a deductible expense." (then, as an aside) "We'll just deduct it from our savings.

While, as you mention, the "new devices" solution won't be viable, for a while for anyone; it may never be for most.  What I think we'll get from that is a muddy environment of new and fixed, old and crippled, and old and vulnerable - all having to interact, at some level.

Another issue with the new-device solution is the 800lb gorilla in the room: what happens when a new hardware vulnerability is discovered in those? 

We may need some BIOS/OS solutions that keep the old devices viable, short-term; and to start mapping out a new paradigm, long-term. 

Just wondering if on-chip security was really the best path, to begin with?  It's like designing a hammer that will prevent you from hitting your own thumb.  Yes, that could work; but then you'd have to design and buy new hammers for every other misuse someone could think of.  Maybe better to leave the tool simply as a tool, and control the how, where and when of its use.
Kelly Jackson Higgins
50%
50%
Kelly Jackson Higgins,
User Rank: Strategist
1/30/2018 | 2:24:55 PM
Re: A question for DR
You raise a really good point:

Another issue with the new-device solution is the 800lb gorilla in the room: what happens when a new hardware vulnerability is discovered in those? 

That is a very real possibility, and indeed it does question how Intel (and its competitors) can better build on-chip security, factoring in future flaw finds and update processes.  
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
1/30/2018 | 7:17:52 PM
How about new chips
I am wondering if intel has a real solution to the problem, are they fixing the new CPUs that they produced?
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
1/30/2018 | 7:19:22 PM
Re: A question for DR
Once we learned that underlying vulnerability was multi-chip-vendor (so multi-OS and Applications), we knew a long series of mitigation and fix iterations was inevitable. That makes sense. Hopefully these variants will end soon.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
1/30/2018 | 7:20:33 PM
Re: A question for DR
Would the last few weeks of chaos been avoided, if the confidentially informed vendors had more time before public disclosure? I hear you, I would say it would be the same, they would not take action until last minute.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
1/30/2018 | 7:22:06 PM
Re: A question for DR
The patches/updates were obviously rushed without time to properly vet and test them. That makes sense. They would still see problems when they deploy it to mass market.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
1/30/2018 | 7:23:43 PM
Re: A question for DR
The patches don't really fix anything--they just mitigate exploits- I think that is why we need to go to a real solution, performance hit is not really acceptable.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
1/30/2018 | 7:25:30 PM
Re: A question for DR
The real fix to these flaws is a new generation of microprocessors, which will likely take years for most organizations to adopt. That makes sense, I am also wondering if there is way to fix exiting CPUs for new devices.
Page 1 / 2   >   >>
Why Cyber-Risk Is a C-Suite Issue
Marc Wilczek, Digital Strategist & CIO Advisor,  11/12/2019
Unreasonable Security Best Practices vs. Good Risk Management
Jack Freund, Director, Risk Science at RiskLens,  11/13/2019
6 Small-Business Password Managers
Curtis Franklin Jr., Senior Editor at Dark Reading,  11/8/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-18986
PUBLISHED: 2019-11-15
Pimcore before 6.2.2 allow attackers to brute-force (guess) valid usernames by using the 'forgot password' functionality as it returns distinct messages for invalid password and non-existing users.
CVE-2019-18981
PUBLISHED: 2019-11-15
Pimcore before 6.2.2 lacks an Access Denied outcome for a certain scenario of an incorrect recipient ID of a notification.
CVE-2019-18982
PUBLISHED: 2019-11-15
bundles/AdminBundle/Controller/Admin/EmailController.php in Pimcore before 6.3.0 allows script execution in the Email Log preview window because of the lack of a Content-Security-Policy header.
CVE-2019-18985
PUBLISHED: 2019-11-15
Pimcore before 6.2.2 lacks brute force protection for the 2FA token.
CVE-2019-18928
PUBLISHED: 2019-11-15
Cyrus IMAP 2.5.x before 2.5.14 and 3.x before 3.0.12 allows privilege escalation because an HTTP request may be interpreted in the authentication context of an unrelated previous request that arrived over the same connection.