Slashdot Mirror
OpenBSD Chief De Raadt Says No Easy Fix For New Intel CPU Bug 'TLBleed' (itwire.com)
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. iTWire reports: 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."
He said that Williams was lacking all the details and not thinking it through. "They actually have sufficient detail to think it through: the article says the TLB is shared between hyperthreading CPUs, and it is unsafe to share between two different contexts. Basically you can measure evictions against your own mappings, which indicates the other process is touching memory (you can determine the aliasing factors)." De Raadt said he was still not prepared to say more, saying: "Please wait for the paper [which is due in August]."
He said that Williams was lacking all the details and not thinking it through. "They actually have sufficient detail to think it through: the article says the TLB is shared between hyperthreading CPUs, and it is unsafe to share between two different contexts. Basically you can measure evictions against your own mappings, which indicates the other process is touching memory (you can determine the aliasing factors)." De Raadt said he was still not prepared to say more, saying: "Please wait for the paper [which is due in August]."
If not this one, maybe the next bug of this kind will finally put illusion of VM separation to rest. If you are running something in the cloud, there is no way to secure it. Start bringing important stuff back in-house, and better use dedicated hardware. Yes, these old-fashioned blade servers were in the access-controlled server room for a reason.
stupid humans are incapable of making better computers, they insist on broken designs and do not have the intelligence to do better
Time to open a wormhole and revert to older hardware:
https://en.wikipedia.org/wiki/...
Or do THOSE systems have a possible back-door(s) in them?
PCID should help with this kind of vulnerability too.
When mitigating Meltdown, one way was to separate completely the kernel memory from user process memory, this involved switching the virtual paging memory and this flushed TLB entries.
This causes speed decrease. To mitigate this, (some) CPUs have a feature where it writes the process ID into the TLB entry, so it could remain in the cache, but it would remain inactive while another process is running.
While this sound like the perfect solution, the problem is that the ID field is not big enough and should be switched and recycled.
Is this another Intel only bug, or are other processors affected?
Like Meltdown and Spectre, this 'exploit' requires a lot of things to be 'just right' for an exploit or data leak to occur.
I'm not saying they're worthless exploits, but again, when I read some of the particulars about the research.. well this popped out:
The team used AI – specifically, a support vector machine classifier – to identify when a program is executing a sensitive operation, such as a cryptographic function, through the TLB latencies, and read out that app's private data as a stream of bits, allowing them to reconstruct things like crypto keys. There are hurdles to overcome, such as address-space layout randomization – however, the team believes these can be defeated in real-world attacks.
So I really don't know a lot about AI implementations, but I'm going to take a liberty and say, that's probably computationally expensive to be doing. That they needed an AI to even get anywhere examples how sensitive this exploit truly is. Expecting to deploy an AI in the wild (malware) and have it grabbing stuff from whatever... it's a pretty big stretch from these laboratory conditions to real-world.
I'm not going to say there's nothing here, but I am going to say: Where's the beef? Cuz it's awfully small with this exploit, there's much easier ways to steal information.
Lastly, it seems isolated to HyperThreading Intel CPUs, from what I read. Yes, it's a big attack surface, but still.. an exploit working in your special setting doesn't really move me much, especially how special these particular set of conditions were.
but the fact that the vendors put a secret OS with an api within the cpu below the bois/command set? Who thought that was a good idea. And who did not see the problems and issues.
;)
I know, I know nothing, I wrote z80 assembly as an intro. I am missing the entire point of what the wise individuals are doing..
Just my 2 cents
We're all doomed now!
How does IBM do hardware partitioning with their POWER chips? I had a box that was partitioned off with PowerVM and decided to run Linux on bare metal. Linux only saw the tiny RAM an CPU slice that PowerVM ran inside. Not until I cleared the hardware with the service processor did Linux see the rest of the resources.
Only the State obtains its revenue by coercion. - Murray Rothbard
We have 64 bits virtual.
Just don't put processes in intersecting address spaces; we already slide them arounbd with ASLR; adding negaffinity is not that hard a modification.
No TLB intersections, no issues.
Yes, performance will be reduced due to not having any page sharing whatsoever.
Alternate fix: stop using hypervisors.
There are so many attack vectors and options, and so much research from a lot of fronts. Soon or later another serious problem will arise because the modern CPUs are just too complex to be 100% safe for everything.
However, the solution seems to be simple. Don't put all the eggs in the same basket.
Use several independent computers. The ones could be exposed to environments where those exploits could be possible, must lack hyperthreading, branch prediction all these fancy speed things. But the ones are behind in really secured areas with enough control and a small quantity of well behaved and controlled software, could use those resources.
The issue here is to design for security and forget the sellers fairy tales about how good are their products.
Support vector machine is a machine learning (now re-buzzed "AI") thing. There's a machine learning MOOC out there that uses SVMs to classify images of hand-drawn numbers into actual numbers. Picture in, digit out. Of course it was a toy problem, but while the matrix math was computationally expensive for my poor old single core box, it is not so much for modern many core CPUs, and it makes pretty good GPGU fodder too. More importantly: The big computational cost is in the training, afterward it's fairly smooth sailing.
So no, the computational cost for at leas that part isn't that big. And since the cache sneak-a-peek trick can be done (as it previously was) from javascript without much problem at all, that's not very computationally expensive either. In fact, I don't think of this as surprising, but merely a demonstration that the previously opened can of cache peeking worms hasn't been emptied yet. And likely won't be for a goodly while.
I went out to *BSD's grave on Decoration Day. The old forgotten cemetery is by the dark woods beyond the edge of town. There within olfactory distance of the municipal treatment plant you will find *BSD's final resting place.
*BSD's tombstone was shrouded by thick mosses and knots of noxious ivy. I gently pulled aside the tangled twists of thorns, and cleaned the decaying marker the best I could. My melancholy thoughts pondered that this indeed was *BSD's figurative charnel house of which so many have plaintively spoken.
Nothing is so pitiful as an untended grave, a loved one now forgotten. The short sad life of this doomed and fated OS make s us realize that there but for the grace of God go all of us.
I planted some wilting marigolds which I had found discarded behind Bud's Garden Center. By some miracle perhaps they will take root and bring a modicum of cheer to BSD's God forsaken plot. My fervent hope is that the torpid colored boy who carelessly mows the cemetery doesn't slice them down, inadvertently mirroring *BSD's own doomed encounter with death's irresistible scythe.
Funny how things work out. Linux, that brilliant novam stellam, now runs the Internet and the world's fastest computers, while *BSD lies moldering within its forgotten crypt. Let the barren silence of *BSD's tomb be a mute reminder that hubris and braggadocio were no defense on that woeful day when the Angel of Death's bleak umbra was cast upon *BSD.
So I really don't know a lot about AI implementations, but I'm going to take a liberty and say, that's probably computationally expensive to be doing.
No, the expensive part is training a model, actually using a trained model to evaluate inputs to check a result just a bit of vector math to flow inputs through a number of very cheap computational nodes that spit out a result... That's why mobile devices can easily do all kinds of image classification now with trained models, even for live video feeds.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I don't think these security issues are accidental.
With the August release date, it will probably be a presentation at defcon
Maybe you could show up and get de Raat to spill da beans to ya
who waste their life coming up with ways to fuck up other peoples' day by hacking their computer.
Pondscum basically. Or pathogenic bacteria. Take your pick. But such is life I guess.
Where are we going and why are we in a handbasket?
Am I to understand that every single performance enchancement made by Intel in the last 20 (?) years is flawed and prone to disaster-bugs?
Each target needs its own model
Each processor, yes. Each target? No.
The behavior of memory and processor caches seems like it would be pretty much the same on any system, in terms of determining a pattern. There are only a few crypto libraries that everyone uses so it's not a vast difference to train a model that handles all commonly used crypto libraries along with common server processors and servers.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
The real fix would affect speed too much which many users would probably find a way to defeat anyway. Unfortunately Intel and even ARM and AMD made some choices in architecture for their CPU's that provided these security issues. Whether they all knew about them at the time is debatable. Going forward I think we will see Intel and to some extent ARM and AMD revert chip design back to a safer architecture.
Wrong. Computer forensics specializes in this sort of data recovery. There's a reason why DoD spec is 7 passes over the disk.
Now SSDs are a different matter.
The DoD spec has been superseded by NIST SP-800-88 (Rev 1), Section 2.4:
For storage devices containing magnetic media, a single overwrite pass with a fixed pattern such as binary zeros typically hinders recovery of data even if state of the art laboratory techniques are applied to attempt to retrieve the data.
* https://doi.org/10.6028/NIST.SP.800-88r1 (PDF)
Using the ATA Sanitize Device /SECURE ERASE UNIT feature set, or SCSI SANITIZE, are sufficient unless you're talking about TOP SECRET labelled stuff. That's if you want to re-use the drive: if not, just sending it through a degausser and fry the thing.
You certainly cant trust the 2 billion Chinese.
Tell us about those NSA chips on harddrive controllers.. go on..
It's an exploit that can potentially steal bits from another VM or process.
That much is clear. What they're not telling you, is how the hell you get from stealing bit streams and exporting them to the outside world. Also they don't tell you how you go about actually capturing bits you might actually be interested in capturing.
OK, so case 1, you rent a VM from a random provider and start fishing around to try and find out what is sharing the bare metal with you. So what? What are the chances of you landing on a bare metal that has ANYTHING useful running along side your maliciousness?
So case 2, you inject this into an actual webserver of interest, by another exploit of some kind. Assuming this alone didn't set off a ton of alarms for a system admin to come look at, you still have to defeat whatever firewalling is present on your target and have THAT not set off a ton of alarms for a system admin to come look at.
Case 3, the end user. The most worthless of all targets, whacha gunna steal? A credit card? Someone's bank account credentials? There's much easier ways to go about this. And more rewarding targets. Bank fraud and computer crimes you'll be charged with are not worth one fuck's bank or credit card. Hell you can just buy that kind of thing on the dark web anyway and charge up some random fuck's credit card.
Bottom line, interesting exploit you have there. Wish it was actually useful in the real-world, but it's not, nor will it ever be. Sorry.