Slashdot Mirror
Academics Publish New Software-Level Protections Against Spectre and Rowhammer Attacks (bleepingcomputer.com)
Catalin Cimpanu, writing for BleepingComputer: Academics from multiple universities have announced fixes for two severe security flaws known as Spectre and Rowhammer. Both these fixes are at the software level, meaning they don't require CPU or RAM vendors to alter products, and could, in theory, be applied as basic software patches.
The first of these new mitigation mechanisms was announced on Thursday, last week. A research team from Dartmouth College in New Hampshire says it created a fix for Spectre Variant 1 (CVE-2017-5753), a vulnerability discovered at the start of the year affecting modern CPUs. Their fix uses ELFbac, an in-house-developed Linux kernel patch that brings access control policies to runtime virtual memory accesses of Linux processes, at the level of ELF binary executables.
[...] The second fix for a major flaw announced last week came on Saturday from the Systems and Network Security Group at VU Amsterdam. Researchers announced a new technique called ZebRAM that they said is a comprehensive software protection against Rowhammer attacks.
The first of these new mitigation mechanisms was announced on Thursday, last week. A research team from Dartmouth College in New Hampshire says it created a fix for Spectre Variant 1 (CVE-2017-5753), a vulnerability discovered at the start of the year affecting modern CPUs. Their fix uses ELFbac, an in-house-developed Linux kernel patch that brings access control policies to runtime virtual memory accesses of Linux processes, at the level of ELF binary executables.
[...] The second fix for a major flaw announced last week came on Saturday from the Systems and Network Security Group at VU Amsterdam. Researchers announced a new technique called ZebRAM that they said is a comprehensive software protection against Rowhammer attacks.
Don't publish a freaking paper, send a goddamn diff on the LKML, and we'll be able to comment. This PR-seeking behavior from researcher is pretty deplorable.
So why should AMD systems slow down to cover Intel? or say in a system where I don't need security like this but need speed?
At least with linux I can force it off at the kernel level.
Publicity for an academic paper, on the other hand, can lead to funding.
Here's my fix for rowhammer and spectre:
Unfortunately this might still be vulnerable to TLB attacks, so there's an improved version:
Here's how you might use it:
You can never be too safe! /s
Software can be subverted, these flaws have to be addressed in hardware redesign
Yes, let's take us some juicy hardware problems and fix'em in software!
Well, that's not an especially good idea, even if you can successfully do it.
At the same time, msmash is still high on bleepingcomputer. Rehab is calling, dear. And get us some real links while at it.
Because people get paid by/are afraid of Intel and completely lack any kind of moral fiber. Lots of people working on Linux for instance are employed directly or indirectly by Intel. No wonder AMD had to fight pretty hard to put a stop on the original plan to "secure" all x86 CPU's against Meltdown - which, as far as x86 goes, is an Intel exclusive.
This is Spectre 1, not Meltdown. I believe it also affects AMD. IIRC, it was also expected to be quite difficult to implement, though I didn't hear any follow-up about that.
I also didn't hear that Rowhammer was specific to Intel. Do you have reason to believe differently?
FWIW, and IIUC, while Linux allows you to disable the protection against Spectre (or was it Meltdown), the kernel automatically optimizes it away if the processor is not vulnerable. (IIUC, the original patch submitted by Intel didn't do that, but AMD submitted a revised patch.)
I think we've pushed this "anyone can grow up to be president" thing too far.
Yes I realize someone could figure out a mass application exploit at any time now, but are there any actual active threats out there besides the mental scare tactics currently imparted by all the news outlets?
Found the Intel shill! Seriously, though - there is no reason to believe they are not in active use. The time between a vulnerability being publicised and seen being exploited as part of a professional criminal exploit in the wild is generally under two weeks. After all, you don't leave your car unlocked because nobody has stolen it yet.
After the moderate success of the Pentium 3, when AMD and Intel were pretty level, Intel went NETBURST.
Netburst was an ultra long pipeline design chasing 10GHz. It was the biggest disaster in x86 architecture to date. As it became clear to Intel that AMD would trivially defeat netburst with its own x64 design, Intel infamously went back to the Pentium 3, updated the architecture, and made Core 1/Core 2 which eventually became todays vastly improved core architecture.
Intel used AMD patents for the core 2, while AMD (in an act of unthinkably stupidity) used Intel Netburst patents to design AMD's own disaster, Bulldozer. The two companies have a cross patent sharing agreement.
Now how does this fit into the 'spectre' etc current dister for all Intel parts on sale today (but not AMD's incredible Zen)? Well it turns out that when Intel driopped Netburst, and built core 1/core 2 on the back of the Pentium 3, to give themselves a FAKE NEWS perfromance boost, they dropped all hardware privilege testing of memory access.
An analogy. When a modern multi-threading program accesses memory, it should work like a key opening a chest. Without the right key, you cannot look in the chest. But the very handling of 'keys' and the time it takes to unlock the 'chest' and look inside has an impact on performance. It turns out that after Netburst, as all modern processors went multi-core (then simulatneous mutli thread per core) Intel never implemented the lck and chest approach that is essential to secure processing.
AMD did. The bulldozer underperformed against the intel equivalents cos AMD had the lock and chest and Intel did not. Intel's performance advantage, in other words, comes from pure hardware cheating. Put the hardware lock and key back in, and Intel would fall way behind AMD's current ZEN design (and zen is already faster on instructions per clock when code is optimised for both Intel and AMD- which sadly rarely happens with commercial code, which is optimised for Intel only).
So for all the years Intel cheated and had dangerous and incorrect processing design, how did they get away with it? By conspiting with Microsoft to use atrocious 'code memory domain' methods. This is a software technique that forms trust based seperation of assets owned by threads. But low level black-hat code can always subvert this OS fantasy, and use the lack of proper memory hardware on Intel CPUs to allow one thread to read the assets of another.
Also, the Intel cheat met the needs of the NSA, CIA, GCHQ etc in making every PC insecure.
How do you fix any of Intel's current CPU's? By running only ONE thread at a time on the chip, and doing a complete state flush when a new thread is given its time slice. A current 4 core 8 thread Intel i7 would fall to less than 5% of its current max performance if an ordinary OS were forced to do this- which in reality is the ONLY secure fix for Intel parts.
TLDR- Intel x86 CPU's post netburst (all the 'good' chips from the last 10+ years) are faulty by design, where the purposeful memory architecture fault gives Intel a massive unfair thread memory speed advantage, and allows the NSA to use user level code to interogate even Ring Zero assets on any Intel CPU.
Intel needs an entire new architecture to 'fix' the fault (won't happen for at least three years), and even then Intel will then lag far below current AMD CPU designs.
The same assholez who sunk us in this muck are now suddenly here to save us? Fuck that.
INTEL OWES US MONEY.
Tell us where the Professor touched you.
if only I could have enjoyed witnessing the spending of close to EUR50k of useless spending for no other sake than spending money to justify the next funding cycle...
"Seriously, though - there is no reason to believe they are not in active use. "
How about the fact that these are post exploit payloads that won't get you into anything. And they aren't useful unless you broke into a virtual machine. So you can spy on the other VMs on that system. Well you could have just pivoted and owned every virtual instance...
I thought rowhammer was a done deal solved by "scrambler" features of memory controllers?
What we're seeing now is just the tip of a very very large iceburg requiring fundamental design changes involving the rolling back of years of clever performance enhancing shortcuts.
Introducing software patches is counterproductive at this point in time. If you care about security the ONLY viable option right now is metal.
What ELFbac is doing is to partition the memory space into regions with different protection depending on which region the access is coming from.
You could say that it is like automated partitioning of a program into multiple processes communicating via shared memory.
The cool feature here is that the access control matrix is derived from the existing link information in the binary itself (ELF format), which means that no code rewrite is necessary.
I'm not sure how it would stop Spectre though, especially on Intel which runs code speculatively before access control. I'm looking forward to reading the paper (especially since I'm already drawing ideas from it to another project ...)
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
There are working examples in browser javascript. That's hardly "post exploit payload" I also congratulate you on your exceptionally narrow world view in that the only way you can see this exploit being used is in crossing container memory boundaries.
If you make sure you have quality RAM ICs (Samsung at the moment), do not drop your RAM voltage too low and do not reduce the access latency too low then you can make rowhammer attacks near impossible, if not impossible. You will also reduce bit flips to between zero and a few per year for your workstation. I read 5 or so research papers on ECC vs non-ECC and that's a summary of what I was able to learn.
If you have a GPU with ECC then the recommendation is to turn off ECC. The GPU will be faster and more reliable for scientific simulations, with ECC off. Bit flips and errors caused by the memory controller with ECC on are more frequent then bit flips caused by cosmic rays. If you are in space or at an extremely high altitude then cosmic rays are a problem.
In fact I have posted here on Slashdot that an API at the OS level can fix all this CPU bug, that's when this Spectre and Meltdown were exaggerated on almost all tech sites. Any hardware bugs can be fixed by software, and vice versa. Software bugs can also be bypassed by modifying hardware too.
Computer Science fundamentals 101