OpenBSD Chief De Raadt Says No Easy Fix For New Intel CPU Bug 'TLBleed' (itwire.com) 123
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]."
Illusion of speparation in VM (Score:5, Insightful)
Re: (Score:2, Interesting)
If we'd be willing to deal with choppy timeslicing where you give the whole processing (all cores & GPU) away for a longer timeslice and fully scrub cache state between and swap for a whole new RAM bank, you could probably start to think about making some guarantees.
But damn that throws away so much performance and response speed.
Of course the world will settle somewhere between that extreme and the current state (probably much closer to the current state for a while).
Re: (Score:1)
If we'd be willing to deal with choppy timeslicing where you give the whole processing (all cores & GPU) away for a longer timeslice and fully scrub cache state between and swap for a whole new RAM bank, you could probably start to think about making some guarantees.
But damn that throws away so much performance and response speed.
Only response speed. Longer slices will increase performance.
Re: (Score:2)
Could you do this if you somehow flipped around the CPU trends? What if instead of two-socket servers with 16 cores per socket, we had 8 sockets with 4 cores per socket?
Re: (Score:2)
They wouldn't need to be separated by a socket.
In this case, as far as I can tell, it's hyper threading, so treating your 16-core cpu as 16 processors is ok (in this specific case) but not as 32 processors.
Of course, they have a lot of sharing within the processor package and it seems plausible for there to be issues like this suggesting more isolation/dedicated resources, but that still can be done in a single processor package too.
Re:Illusion of speparation in VM (Score:4, Interesting)
Take a cue from the C++ people. VM separation protects you from Murphy, not Machiavelli.
Re: (Score:2)
VM separation protects you from Murphy, not Machiavelli.
This is the quote of the day.
But now I have to wonder which your .sig is. ;)
Re: (Score:2)
VM separation protects you from Murphy, not Machiavelli.
Brilliant.
Re: (Score:3)
You have to weigh the possibility of an unpatched cloud server being compromised by a neighbouring VM against the possibility of your own in-house servers being hacked.
Cloud companies so security on a massive scale and all the big guys like Amazon, Microsoft and Google have a track record of keeping their systems up to date and secure. It's no wonder, because they can afford the best security staff and security is a core part of their business.
Your locked server room looks impressive but is reliant on who y
Re: (Score:2)
Cloud companies so security on a massive scale and all the big guys like Amazon, Microsoft and Google have a track record of keeping their systems up to date and secure. It's no wonder, because they can afford the best security staff and security is a core part of their business.
Well... In that particular case, Amazon, Microsoft and Google are "more" secure because Intel gave them advance warnings and probably some detailed patch and vulnerability information. And Linux got patched really quickly because Google and Amazon have invested massively in that operating system.
The smallest projects, like OpenBSD, were left in the cold to fend off for themselves. Theo and other developpers asked Intel if they could be a part of the embargo. They never received a response.
Re: (Score:2)
Re: (Score:2)
There's a big question as to whether the cloud servers *CAN* be patched. This latest round of bugs seem to all depend upon hyperthreading implementations in the microcode. Intel's recent history of patching that kind of thing is dubious, to be kind. And actually with a bit of outright malicious thrown in. (Linus was quite upset.)
Personally, I'm dubious about the whole hyperthreading architecture. I think they should go/have gone with lots more simpler processors.
Re: Illusion of speparation in VM (Score:2)
Is the same tlb bleed problem inherent and the AMD ryzen computer chips?
Re: (Score:2)
very funny, since that mostly happened in Bush and Obama years
Re: (Score:1)
OMG, Obama's admin pushed like they were pushing a beech ball through a 2" pipe. The told the Military to do it. Still dealing with that crap.
Re: (Score:2)
The problem is the douchebag humans (Score:2, Insightful)
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.
Re:The problem is the douchebag humans (Score:4, Interesting)
[The problem is the douchebag humans]
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.
There will always be a criminal element in any free and open society. That's really just human nature.
No, the real problem here are governments that insist people not be *too* secure in their data, communications, and with whom they associate (there is no freedom of association if all your associations are tracked, stored, and analyzed).
Strat
Oh The Simplicity of Contiki! (Score:1)
Time to open a wormhole and revert to older hardware:
https://en.wikipedia.org/wiki/... [wikipedia.org]
Or do THOSE systems have a possible back-door(s) in them?
Re: Oh The Simplicity of Contiki! (Score:1)
I have often thought that instead of 'throw away and replace,' software should continuously improve. The software that was 'good enough' to run on old Pentium 3 systems back when that was the 'leading edge' hardware should be better, and run even more efficiently today. Because there has been the time to improve it. To improve the libraries it links to. Ultimately for every part of it to be replaced by hand coded assembly language. Think of Wordstar, written in assembly language, that runs usably well on a
PCID should help. (Score:3)
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.
Intel only (Score:2)
Re: Intel only (Score:2)
My SparcStation IPC is safe. Uses regular old 30 pin DIMM memory, even.
Re: (Score:1)
You can count on Intel to bring out another bug (does not matter how critical) that also affects AMD and scream it up the flagpole so people will figure AMD is just as bad as Intel... it's what they do
Re: (Score:2)
It appears to be a new vector for well-known crypto key-derivation side channel timing attacks.
The CPU isn't really leaking anything from the sounds of it, they're just using the fact that the TLB is shared between threads as a way to statistically derive the key schedule of a well known and profiled encryption library.
I'm not familiar with AMDs architecture, so I can't speak as to whether o
Special settings (Score:5, Insightful)
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.
Re: (Score:2)
Re:Special settings (Score:5, Insightful)
Theo: Worried
Random Slashdotter: Not so worried
No offense, but I’ll go with the OpenBSD and LibreSSL guy on security matters.
Re: (Score:2)
Why? Generally security guys love raising hypothetical, navel gazing, wank, think-pieces to look clever.
Case in point, the amount of utterly #@$%ing stupid security guys who insist on quadruple random pass on hard disks to wipe, /then shredding them physically/.
In reality there's never been a proven case of restoring data from a hard drive that's been written even just once with 0s.
I'd be comfortable stating on my experience, over 85% of security people I've encountered in the industry to be nothing but a h
Re: (Score:2)
Same with random key generation. Stupid programs make me sit there and move the mouse randomly for 2 minutes, instead of just taking some bits from /dev/urandom, which is just as good.
Re: (Score:2)
Re: (Score:3)
Case in point, the amount of utterly #@$%ing stupid security guys who insist on quadruple random pass on hard disks to wipe, /then shredding them physically/.
I always thought that was sort of a "guy thing". I've had fun drilling holes through hard drives, then crushing them in vices. Even took a few to the rifle range. When in fact, I knew that:
In reality there's never been a proven case of restoring data from a hard drive that's been written even just once with 0s.
Pretty much this. Early on, I asked how exactly data could be retrieved from an overwritten drive, and got a strange "edge of the written area" response. Then I asked why the new data wouldn't write to the "edge of the written area". Didn't get an answer.
I'd be comfortable stating on my experience, over 85% of security people I've encountered in the industry to be nothing but a hindrance, who love saying no to things, for the sake of looking important.
That's a bit harsh. There is an old saying that you can't know what
Re: (Score:3)
The reason is that it might have been possible, back when track width was much wider and head positioning accuracy was much lower.
one wipe is good enough (Score:1)
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.
Re:Special settings (Score:4, Insightful)
You have to consider the scope though - Both Random Slashdotter's lack of concern and Theo's worry are justified in my opinion.
Theo: is developing an operating system that is supposed to be essentially the most secure choice. He has a user base that will be deploying it on high value targets. High enough value that a state actor or other well funded well connected group might take interest. Such groups would be capable and willing to develop situationally specific malware + exploit code. If I was using BSD/Intel to run my uranium enrichment process - I'd worry.
On the other hand as far as Random Slashdotter goes - He is probably correct that we won't see this as a metasploit module or meterpreter plug-in anytime soon. Its debatable as to if these exploits could be used in the 'wild' without being highly customized for the target by people who have advanced math/comp sci degrees. In other words even if your bitcoin wallet stored on that VPS is worth few hundred thousand its likely impractical to go after you in this way. So being somewhat dismissive about these attacks as an individual is justified as well.
Re: (Score:2)
I'm not Theo, but I do have published kernel-level exploits for Linux/Android in the NVD, so I'm not speaking completely out of my ass. A lot of these recent CPU architecture attacks are pretty weaksauce. They certainly are real fuckups in the concept of process isolation, but the paranoid people like to act like inferring random memory a few bits at a time is going to yield you useful information.
I've done a lot of work breaking into kernels, and getting access
Re: (Score:2)
Seems like a VPS instance could easily use this to break into its host or to sibling VPSes.
Re: (Score:2)
Like Meltdown and Spectre, this 'exploit' requires a lot of things to be 'just right' for an exploit or data leak to occur.
Look up "heap spraying" to see the kind of extreme techniques that can exist. Although you can't think of something now, people think of bizarre methods.
A typical technique would be to target a particular popular piece of software, like, openSSL, which is used by basically everything. Then use a shotgun approach, and try the exploit on a thousand (or a million) different computers. Even if only 1% of servers are exploitable, then you can grab a lot of private keys. This is the technique hackers use every
Cost of using AI ML models is very low (Score:2)
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.
Re: (Score:2)
You are misapplying theory here. Look at the mobile case again, image classification can easily be applied cross platforms because the things they are classifying don't change. Just because you have and Android vs an iPhone doesn't make that coffee cup look any different.
However in this case the model that needs to be built is the one based on the computer memory. Each target needs its own model which is precisely why the Spectre and Meltdown attacks are essentially irrelevant outside of very specific scena
No, models very general (Score:1)
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.
Re: (Score:2)
No, the expensive part is training a model,
The timings you get from training are only useful if the target machine is IDENTICAL to the training machine. One thing, one little thing to skew the timing just slightly, and it's all over, back to square one.
So again...where's the beef?
Re: (Score:3)
Like Meltdown and Spectre, this 'exploit' requires a lot of things to be 'just right' for an exploit or data leak to occur.
All computer programs require that. It is amazing just how fast and accurately these Meltdown readers can dump out kernel memory. That is just the ones we know of, there are many better ones in the wild, no doubt.
Re: (Score:2)
The thing is, the AI, which is really just a fancy term for a machine-learning classifier in this case, doesn't have to look at all like traditional malware. These types of exploits use information obtained via non-escalated processes and can be as simple as timing info. The AI itself does not even have to run on the cloud - it can simply send t
Re: (Score:2)
True for Spectre (which is practically useless for exploits) but not true for Meltdown which is eminently exploitable - a Meltdown exploit does not need to know the precise location of data in kernelspace in order to access it from userspace. Javascirpt can do it.
I am an old nobody (Score:4, Interesting)
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
Re: I am an old nobody (Score:1)
Minix won't run on a Z80. It will run on an 8088 though.
Tanenbaum, were you right?
Re: (Score:1)
In modern usage, x86 means something pretty different from an 8086 processor. The 8086 was basically an expanded version of an old 8 bit processor. Lots more memory space, segmented addressing, etc. But no protected mode.
Re: (Score:2)
Who thought that was a good idea.
Users who were requesting these features by voting with their wallet through vendors that provided them external to the CPU.
Re:I am an old nobody (Score:5, Interesting)
I know, I know nothing, I wrote z80 assembly as an intro.
I learned on an MITS Altair-8800 computer that my roommate had in college. We played one dimensional, straight-line Pong, and had to flip the front-panel switches to reload the program after shutting it off. (5.1 Audio? Mouse? CRT? Printer? Floppy? Keyboard? Paper-tape? You must be joking.)
After graduation, I ended up at his computer shop running CDOS, a CP/M improvement from Cromemco with hardware. They eventually upgraded from 8080 to a Z-80. Really neat, with those 2nd set of registers. We wrote COBOL and Fortran accounting software using embeeded software overlays and 8" floppies and 5-10M hard drives. (150K? 5 Meg? Is that right?? We only had 64K of RAM though, MAX) for companies.
Hey, did you ever see that Zilog Z-80 paperback book (6"x8"? Weird size.) describing how all of the operations worked in pseudo-code? It was wonderful.
I still have a Z-80 fold-out instruction card. Also an IBM 360 one, much longer. Not much useful now, but extremely useful at the time.
Also, decades ago now, IBM produced (as an experiment, not a retail product) a mainframe computer-on-a-chip, but supposedly the firmware was changeable to directly run binary code from IBM 360, PDP, Amdahl, and maybe 3 other CPUs. A decade or more later you've got (we had internal Compaq In-Site cards) things which directly control the computer remotely, even when "it's off". I understand the new corporate ones have it all built on the motherboard. Still need power to the PS though, but you could insert floppy images and flash firmware while sitting at your desk. Neat-O!
I used to understand how things worked, down to the bare metal. (Could program PICs and INT handlers and all that. You too, I'm sure. Remember 16550 UART serial chips with 14-byte internal cache? ) I fiddled with AI a bit in college in the late 70s. It was bloomin' math magic then, I could run the simple operations by hand or look at the intermediate data structures. But it was all just random junk -- except it would actually come out with working answers. I can't imagine and don't understand what they're doing now -- and really, I don't actually think they do either.
Re: (Score:2)
was taught FORTRAN at a tiny rural high school in 73-74 because we had a fresh out of collage physics teacher who got an 029 punch card machine from his school U of Wis, River Falls and taught 5 of us after school. As I recall we each had blue and red paperback books.
Was crazy we would sit for hours writing out code on these pads of coding sheets. the sit for hours at the punch card machine, one line of code per card. The send them off to UW River Falls. in a week to 10 days we would ge
Re: (Score:2)
Who thought that was a good idea.
That would've been the intelligence services; the CIA makes sure it has plenty of control [wikipedia.org] over tech companies.
Re: (Score:2)
There are good reasons for adding another "secret" (not relevant) OS with a separate processor to a computer. How it was done can be discussed.
How does IBM do it? (Score:2)
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.
Re: (Score:2)
"How does IBM do hardware partitioning with their POWER chips?"
Poorly. POWER is vulnerable to both MELTDOWN and SPECTRE.
We have 64 bits virtual. (Score:2)
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.
Re: (Score:2)
We have 64 bits virtual.
No we don't. We have 48-59 bits, depending on the particular microarchitecture. You can exhaust 48 bits pretty quickly if each process wants 32 bits of address space and many things want more because they like to have big gaps to make memory safety bugs more likely to crash.
Design for security (Score:1)
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 a
Re: (Score:2)
Hm (Score:4, Insightful)
Re: (Score:3)
AMD CPUs have many of the same features---TLBs, speculative execution, hyperthreading---without sharing all of the same vulnerabilities. There is enough overlap to suggest there are some unavoidable risks with performance-enhancing features.
It appears Intel was particularly blind to those risks, but bear in mind that some of those vulnerabilities are present on AMD as well.
Since Intel alone was called out on this, I assume AMD's hyperthreading design is safe---for now. Since both hyperthreading designs show
Re: (Score:2)
Re: (Score:3)
Pretty much all CPU vendors were vulnerable to Spectre. Intel helpfully patented the technique that led to Meltdown, so the only non-Intel chip that was vulnerable was a very recent ARM core (released just after the patent expired, such bad timing!). Some of the more recent vulnerabilities rely on particular microarchitectural choices, so are probably limited to Intel. I suspect that other out-of-order cores will have some similar issues, but Intel is in most machines in all of the big cloud data centres
So what? (Score:2)
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 landi