SoylentNews is people
SoylentNews
from the I-predict-another-one-in-six-months-tops dept.
Recompiling is unlikely to be a catch-all solution for a recently unveiled Intel CPU vulnerability known as TLBleed, the details of which were leaked on Friday, the head of the OpenBSD project Theo de Raadt says.
The details of TLBleed, which gets its name from the fact that the flaw targets the translation lookaside buffer, a CPU cache, were leaked to the British tech site, The Register; the side-channel vulnerability can be theoretically exploited to extract encryption keys and private information from programs.
Former NSA hacker Jake Williams said on Twitter that a fix would probably need changes to the core operating system and were likely to involve "a ton of work to mitigate (mostly app recompile)".
But de Raadt was not so sanguine. "There are people saying you can change the kernel's process scheduler," he told iTWire on Monday. "(It's) not so easy."
(Score: 3, Informative) by DrkShadow on Tuesday June 26 2018, @04:23AM
You need to consider the business case.
What can you do? -> Take vulnerable machines out of vulnerable areas.
How important is it that those machines be kept secure? Is it "fairly" important? or is it absolutely, life-riskingly critical? If the former, then how likely is it that your network will be breached, and the machine will be breached, and how likely is it that someone cares enough to do that, and what mitigations do you have in place already? What is the cost of additional mitigations (developer time, morale, solution cost), and what's likelyhood of those preventing a breach? What, then, is the actual cost of a breach?
If it's life-riskingly critical, then you should be considering taking those machines off the network. Air-gapped machines are a great deal harder to compromise, and with proper policies forbidding things like USB-key usage (I mean locks in the USB ports), it's an effective means of protection. Is the level of risk worth the slow-down for developers, being unable to look things up and quickly/easily fix code? Is the risk such that you need to prevent developers from going in or out with USB keys?
You need to make a business case, establish the mitigations (not fixes -- there will always be another hole, but make it so that it takes too long to reasonably find/exploit those holes), and justify that cost as being more worthwhile than the alternative.