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.

Comments
Microsoft Issues Emergency Patch to Disable Intel's Broken Spectre Fix
Threaded  |  Newest First  |  Oldest First
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:34:02 PM
Re: A question for DR
That is a very real possibility, and indeed it does question how Intel (and its competitors) can better build on-chip security, Intel has mot steak in this than others so it would be more important for them to get it right.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
1/30/2018 | 7:29:42 PM
Re: A question for DR
what happens when a new hardware vulnerability is discovered in those? That will be a real blow to intel, they my even go out of business for that.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
1/30/2018 | 7:32:39 PM
Re: A question for DR
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 That is a real good question to ask. Any flow in HW would be hard to fix, maybe we need to evaluate options for HW independence.
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.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
1/30/2018 | 7:26:34 PM
Re: A question for DR
How are things going at your organization? We are mainly applying patches released by Microsoft. Not much other options.
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.
BrianN060
50%
50%
BrianN060,
User Rank: Ninja
1/30/2018 | 7:42:22 PM
Re: A question for DR
@Dr.T. "...Hopefully these variants will end soon."  I don't see how they could - but then I'm not on conference calls with the big players.  Maybe they have, or can, come to an agreed roadmap of mitigation waypoints, towards a solution.  If so, that would be a real achievement.  Without that, whatever one does will tilt the table for the others.  That goes for chip/OS and OS/ISVs (so chip/ISVs, as well).  With the pressure (public, political, contractual), on all of them, I imagine it's like playing the Twister game paced to a Bach Fugue. 
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: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?


When It Comes To Security Tools, More Isn't More
Lamont Orange, Chief Information Security Officer at Netskope,  1/11/2021
US Capitol Attack a Wake-up Call for the Integration of Physical & IT Security
Seth Rosenblatt, Contributing Writer,  1/11/2021
IoT Vendor Ubiquiti Suffers Data Breach
Dark Reading Staff 1/11/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2020: The Year in Security
Download this Tech Digest for a look at the biggest security stories that - so far - have shaped a very strange and stressful year.
Flash Poll
Assessing Cybersecurity Risk in Today's Enterprises
Assessing Cybersecurity Risk in Today's Enterprises
COVID-19 has created a new IT paradigm in the enterprise -- and a new level of cybersecurity risk. This report offers a look at how enterprises are assessing and managing cyber-risk under the new normal.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-25533
PUBLISHED: 2021-01-15
An issue was discovered in Malwarebytes before 4.0 on macOS. A malicious application was able to perform a privileged action within the Malwarebytes launch daemon. The privileged service improperly validated XPC connections by relying on the PID instead of the audit token. An attacker can construct ...
CVE-2021-3162
PUBLISHED: 2021-01-15
Docker Desktop Community before 2.5.0.0 on macOS mishandles certificate checking, leading to local privilege escalation.
CVE-2021-21242
PUBLISHED: 2021-01-15
OneDev is an all-in-one devops platform. In OneDev before version 4.0.3, there is a critical vulnerability which can lead to pre-auth remote code execution. AttachmentUploadServlet deserializes untrusted data from the `Attachment-Support` header. This Servlet does not enforce any authentication or a...
CVE-2021-21245
PUBLISHED: 2021-01-15
OneDev is an all-in-one devops platform. In OneDev before version 4.0.3, AttachmentUploadServlet also saves user controlled data (`request.getInputStream()`) to a user specified location (`request.getHeader("File-Name")`). This issue may lead to arbitrary file upload which can be used to u...
CVE-2021-21246
PUBLISHED: 2021-01-15
OneDev is an all-in-one devops platform. In OneDev before version 4.0.3, the REST UserResource endpoint performs a security check to make sure that only administrators can list user details. However for the `/users/` endpoint there are no security checks enforced so it is possible to retrieve ar...