Slashdot Mirror
Dell and HP Advise All Their Customers To Not Install Spectre BIOS Updates (bleepingcomputer.com)
An anonymous reader writes: The Spectre and Meltdown mess continues with Dell now recommending their customers to not install the BIOS updates that are supposed to resolve the Spectre (Variant 2) vulnerabilities. These updates have been causing numerous problems for users including performance issues, boot issues, reboot issues, and general system stability. Due to this, Dell EMC has updated its knowledgebase article with a statement advising customers to not install the BIOS update and to potentially rollback to the previous BIOS if their computers are exhibiting "unpredictable system behavior". ZDNet reports that HP too has issued a similar advisory. The computer manufacturer pulled its softpaqs BIOS updates with Intel's patches from its website, and said it would be releasing a BIOS update with a previous version of Intel's microcode on Thursday.
People still haven't gotten the point - this is testament to Intel's PR efforts to obfuscate the facts. It seems the majority of people believe that Spectre (affects Intel, AMD and ARM) is just as dangerous as Meltdown (affects only Intel CPUs). Un-fucking-believable. We truly live in the epoch of idiocracy.
"The agriculture ministry is not in charge of Gundam" - Japanese ministry official.
Considering how poorly Intel has handled this, I'm looking forward to seeing the legal consequences.
Intel's performance so far seems best described as "clown show." Especially for major, industry-wide patches that they should be sure will fix the problem without introducing crippling problems that are just as bad (or worse) than the original problem.
Meltdown is an Intel only problem. Don't be fooled by people who say "but ARM is affected too". Baloney. None of those ARM processors are even on the market. And those ARM processors were co-designed by Intel.
In spite of it being perhaps more difficult to exploit, I have the impression that large data centres operating virtual private servers (commercial and corporate alike) have good reasons to be seriously concerned about Spectre.
Citing Forbes, Wikipedia’s article on Spectre says: “Spectre has the potential of having a greater impact on cloud providers than Meltdown. Whereas Meltdown allows unauthorized applications to read from privileged memory to obtain sensitive data from processes running on the same cloud server, Spectre can allow malicious programs to induce a hypervisor to transmit the data to a guest system running on top of it.”
By contrast, Wikipedia’s article on Meltdown says: “Meltdown attack cannot be used to break out of a virtual machine.” (Of course, Meltdown is nonetheless a critical problem, for other reasons.)
Thanks. We will let HP and Dell know.
ARM is probably the only one of the chipmakers doing the right thing here. Information is quick, public, to the point and fixes are deployed as soon as they are done. There are performance issues with ARM patches but they are taken as necessary.
They just got lucky to be right most of the time.
(Helps that they use a much simpler RISC architecture : Their engineer have probably less to review until they can give a definite answer about what is exploitable.
They can mass-exclude any ARM core that doesn't do speculative execution at all (e.g.: RaspberryPi) ).
AMD is just ignoring it altogether until they no longer can. Regarding Spectre: near zero chance > microcode and software updates are coming, this you can read in statement on their page.
Mordern CPUs *are* complex, it's not impossible for not everybody in a company to know every single details.
Spectre variant 2 is the perfect exemple : ."switch" block into machine code.
Variant 2 Spectre works by relying on extremely precise gory detail of the implementation of speculative execution around indirect jumps whose destination isn't even known at execution time
(e.g.: a jumptable whose index depends on a result that isn't computed yet.
e.g: That's one possible form to compile a C/C++
That's also what happens when you need to call the virtual overloaded member function of a C++ object member of an array and you haven't computed the index into the array yet)
The Google demo code relies on the format of the internal data that the branch predictor uses to makes it best guess to where this as of yet unkown destination isn't know.
(Basically, the CPU keeps notes of where it jumped-to most of the times during the past when encountering this point of code.
But the way the CPU write down "this point of code" in it notes is actually imprecise and can lead to confusion.
More or less, it's a hash and Google has found a way to cause a hash collision.
The attacker causes their own attack-program to jump to position A, whenever execution arrives at instruction B.
Then the exploited program reaches a different instruction C, but the CPU is confused and thinks it's again at instruction B, and jumps to position A "out of habit" based on its notes, even if in the exploited program, there's no way this could happen ever (e.g.: there's no "position A" listed in the jump table). )
Should Intel admit that they are vulnerable ? Yes, Google caught them with their pants down on this one.
But, the Intel Xeon exploited by Google demo code certainly works completely differently than any AMD CPU.
So for sure they can guarantee that the exact exploit code won't work for on AMD CPUs
(It would be reasonnable guess, even without speaking to any engineer)
Now: is it definitely impossible to somewhat exploit the jump prediction in a globally similar way ?
Well difficult to exclude.
AMD would need to discuss it at lengths with their engineers experts in branch prediction on their CPU.
So first "nearly-zreo" (Shouldn't not work, but who knows ?)
And then, once AMD manages to get hold eventually of the guy who knows: Oh, shit, it turns out there could be a completely different method that could perhaps be applied to exploit indirect jumps on some recent architectures.
So update the page to tell people to do the updates (while continuing to review with the engineer to try to give an actual answer whether there is actually a viable exploit).
AMD are trying their best, but CPUs are complex stuff, and it's not easy to give a definitive answer fast.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Well at least, look on the bright side :
even if you brick the mainboard into an unbootable state with the bad firmware upgrade,
you can still log into the Intel ME / Intel AMT web-interface running on the ARC core in the chipset, and flash another version from there.
Better than needing to physically walk to the bricked machine, open it, remove the firmware EEPROM chip from the socket, put it into your own EEPROM programmer, reflash a different version and put it back together.
A.K.A.: the only time where Intel AMT works as it should and is actually useful.
A.K.A.: even a stopped clock is right twice a day.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Anyone know what Intel stock is doing these days?
In spite of it being perhaps more difficult to exploit, I have the impression that large data centres operating virtual private servers (commercial and corporate alike) have good reasons to be seriously concerned about Spectre.
Yes. Basically Spectre "Variant 2" / "Branch Target Injection" would allow to rent a VM on Amazon's cloud and spy on any other VM that runs on the same physical CPU.
“Spectre has the potential of having a greater impact on cloud providers than Meltdown. Whereas Meltdown allows unauthorized applications to read from privileged memory to obtain sensitive data from processes running on the same cloud server, {...} Wikipedia’s article on Meltdown says: “Meltdown attack cannot be used to break out of a virtual machine.” (Of course, Meltdown is nonetheless a critical problem, for other reasons.)
Meltdown / "Rogue Data Cache Load" specifically can access kernel (protected) memory.
It is something specific to Intel CPUs.
In order to make a few micro-improvement for speed, Intel CPU only check for protection at the last moment before committing the results to memory/register.
That means that speculative execution might get pas memory protection.
Your run a piece of software, your piece of software tries to read stuff from the kernel, the CPU does it speculatively, touches a few cache, and only then kicks the execution out. You can guess stuff by measuring which caches were touchs.
It works to get across the kernel/user-space boundaries. Gives you ability to peek into the kernel memory space.
It's madness that completely fucks up the base guaranties that memory protection is supposed to provide.
AMD CPU are confirmed to be not affected (they do the costly memory protection earlier and refuse to access protected memory).
Only a couple of ARM Cortex cores seem to be affected (basically only Cortex-A75 is affect in a way that is actually exploitable, according to ARM).
Spectre can allow malicious programs to induce a hypervisor to transmit the data to a guest system running on top of it.
Please pay attention that there are 2 different Spectre attacks.
Spectre Variant 1 / "bounds check bypass" amd Spectre Variant 2 / "branch target injection"
The comment is only valid for the second one.
Variant 1 is just speculative execution working as it is supposed to do. If there's a condition (an "if" in the code) the predictor will try to guess which code path is the most likely to be taken, and speculatively execute that one. If the guess was wrong, the CPU throws the computation an restarts the correct branch. (but again, cache might have moved around and is something that is indirectly measurable).
If the condition is a boundary check, is might get skipped and CPU attempts to speculatively execute reads that are outside the bounds.
That's still reads to memory that should be accessible to the application anyway (meh). That would just cause the application to read one of it other's variable, instead of the array.
It's only a potentially exploitable situation when the application should not read it own data. Usually situations where arbitrary externally provided code reside in the same process as secret data. (And you basically deserve what you get for mixing sensitive data and arbitrary remote code in the same process).
Google example is done by sending eBFP a special type of bytecode used by modern packet-filters to the kernel. It's get jitted to machine code, and such code can read past its boundary speculatively.
Possible other exploit are sending specially crafted Javascript (there's a ASM.js demo floating on the web) or WASM, to a browser which JIT it and execute it. The code translate into a bound check, and could read any other part of the memory inside
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
I couldn't help but notice that the package "intel-microcode" was updated today. Given that I already had the 20180801 microcode installed I looked up the version of the package: "intel-microcode 3.20180108.0+really20170707ubuntu16.04.1"
That's an interesting package management technique.
Spectre Variant 2 is also heavily CPU specific.
The exploit needs to know how the predictor used for indirect branches works (i.e. jumps where the destination isn't know yet, like jump tables (ways to do a C/C++ switch) or calling overloaded virtual C++ members in an array of object) in order too fool it and force it to guess wrong and jump to a completely wrong destination.
It's been demonstrated on Intel CPU.
ARM reports that the few Cortex cores that do speculative execution are affected.
(But, no ARM-specific exploit code is mentioned).
AMD knows that the Intel-specific code won't work (duh... obviously), but they cannot exclude that there won't be any way to exploit their indirect branch speculation ("near zero", not "zero" chance). Currently they recommend to apply patche, while they try to work out if there are possible viable exploitable to be made against their indirect branch prediction.
PowerPC G3 and G4 are not exploitable, I've read. They *do* speculative execution. But they either don't speculate around indirect jumps, or don't speculate far enough to be actually exploitable in practice.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
especially when the 'doctor' in this case is known to be a pathological liar.