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.
HP may have pulled the downloads from the website, but their BIOS-embedded flash utility is still able to locate the BIOS versions with the bad microcode on at least one model. If I go through all of the different models at work, I would not be surprised to see all of them picking up the bad BIOS version. I wonder why you cannot just revert the BIOS catalog as well for this...
more likely the bug is being exploited already.
Since my computer started rebooting aswell and it never received ant patch because there most likely won't be one made for i7-3xxx series.
All this over the course of last weekend when a lot of hackertwats were trying their luck.
It's all marketingploy for a failing business. A business that doesn't understand it's own business and thinks it is selling hot cakes when it got nothing in common with hot cakes.
I have a Gigabyte motherboard and a Skylake Core i5 and installed the new BIOS update (which says "Update CPU Microcode") and so far it seems to be going good. No random reboots or crashes and no noticeable slowdowns.
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.)
I just made the fatal mistake of clicking on a ZDnet article just to get to the source material - the HP link - and I happen to not be running ad block on this machine - well that will never happen again - ad block will be installed here too. I was starting to feel guilty about not supporting sites until I saw the vile state of internet advertising for the first time in a few years...
Note to /. editors - please link to source materials as you did with Dell in the future and not lame ad filled articles that link to them.
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 ]
They've gone out of their way to say that 90% of systems with recent Intel processors have been patched. With this announcement from Dell and HP they'll have to lower that percentage. Considering how much Intel likes to spin I suspect they'll say it's now 89% of systems patched.
Anyone know what Intel stock is doing these days?
Change log:
2018/01/01 - Added 14 Useful Links. Disable Intel ME 11 via undocumented NSA "High Assurance Platform" mode with me_cleaner, Blackhat Dec 2017 Intel ME presentation, Intel ME CVEs (CVSS Scored 7.2-10.0)
Intel CPU Backdoor Report
The goal of this report is to make the existence of Intel CPU backdoors a common knowledge and provide information on backdoor removal.
What we know about Intel CPU backdoors so far:
TL;DR version
Your Intel CPU and Chipset is running a backdoor as we speak.
The backdoor hardware is inside the CPU/Bridge and the backdoor firmware (Intel Management Engine) is in the chipset flash memory.
30C3 Intel ME live hack:
[Video] 30C3: Persistent, Stealthy, Remote-controlled Dedicated Hardware Malware
@21:43, keystrokes leaked from Intel ME above the OS, wireshark failed to detect packets.
[Quotes] Vortrag:
"the ME provides a perfect environment for undetectable sensitive data leakage on behalf of the attacker".
"We can permanently monitor the keyboard buffer on both operating system targets."
Decoding Intel backdoors:
The situation is out of control and the Libreboot/Coreboot community is looking for BIOS/Firmware experts to help with the Intel ME decoding effort.
If you are skilled in these areas, download Intel ME firmwares from this collection and have a go at them, beware Intel is using a lot of counter measures to prevent their backdoors from being decoded (explained below).
Backdoor removal:
The backdoor firmware can be removed by following this guide using the me_cleaner script.
Removal requires a Raspberry Pi (with GPIO pins) and a SOIC clip.
2017 Dec Update:
Intel ME on recent CPUs may be disabled by enabling the undocumented NSA HAP mode, use me_cleaner with -S option to set the HAP bit, see me_cleaner: HAP AltMeDisable bit.
Useful links (Added 2018 Jan 1):
Disabling Intel ME 11 via undocumented HAP mode (NSA High Assurance Platform mode)
me_cleaner: Set HAP AltMeDisable bit with -S option
Blackhat 2017: How To Hack A Turned Off Computer Or Running Unsigned Code In Intel Management Engine
EFF: Intel's Management Engine is a security hazard, and users need a way to disable it
Sakaki's EFI Install Guide/Disabling the Intel Management Engine
Intel ME bug storm: Hardware vendors race to identify and provide updates for dangerous Intel flaws.
CVE-2017-5689: An unprivileged network attacker could ga
It is so fun to see still lingering Compaq branding and terminology popping up in HPs plantation.
Shine on Compaq!
The problem is in the microcode of the CPU. This is a problem with how the chips are designed to handle instruction look ahead processing, and as such is Intel's responsibility as they designed and licensed buggy microcode. To fix an issue of this type properly you must fix the microcode AND replace the micro processor. Intel is trying to distance themselves from any responsibility as they would stand to lose a truckload of money replacing CPU chips. But as the continuing problems with the patch issues indicate, you can not fix a problem internal CPU using external measures. This is like trying to fix a leaky pipe in your home by putting a tarp on the roof!!!! Intel's suggesting BIOS and OS patches is a purposeful misdirection of blame in order to avoid a lawsuit. Each day Intel does not PROPERLY address the matter, brings them one day closer to that lawsuit they are trying to avoid.
SELECT * FROM User WHERE Clue > 0
0 rows returned
Heck I installed the bios days ago having been auto updated with Dell's update service. Of course now they tell us its all shit and yet the new bios won't let me down grade either. What a bunch of crap, obviously we all became beta testers because in 6 months Intel or PC makers couldn't possible come up with a stable solution for a chip Intel makes?? How bad is that when you can't fix your own damn product right. Personally, I think every Intel chip sold is bad and will always be bad. Other then completely disabling the hardware to protect from Spectre. We will see a cobbled together band aid to try and limit the exposure.
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 ]
Can I bill intel?
Often sales fine print tries to limit the liability of the part make to the cost of the part. This isn't unreasonable especially if there's no really malice or incompetence involved. While my opinion of intel is in the dump now, I can't honestly say it was truly incompetent. One reason Boeing makes such good airplanes is that WWII taught them every way to make a mistake. Until you make one, you often don't see your own blind spots. One could have hoped for better or more dilligence but that's sort of unreasonable. Take care with your own glass house first.
On the other hand, I didn't sign an agreement with intel, I signed the sales agreement with best buy or Dell or apple, etc... So logically the bill should go to them not intel.
Still the same argument about best effort does apply. But shouldn't they be on the hook not for damages but at least the value of the computer itself as an upper bound.
Some drink at the fountain of knowledge. Others just gargle.
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.
Nope, they said no such thing. They said that 90% of their systems have patches available. Given it was always left to the vendors to issue these patches that 90% figure is not going to happen, at all, and definitely not on the day the microcode was released.
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.
"These updates have been causing numerous problems for users including performance issues, boot issues, reboot issues, and general system stability."
So, these BIOS updates cause system stability? Why wouldn't I want to install them?
A patch that causes systems to reboot or otherwise be unstable is not a viable patch, so my comment stands.
This is ridiculous.
It was never viable to begin with since most vendors would never push it out. Shit the last BIOS update I got was in 2014 and it is marked as Beta.
Also if you want to get realllllllllly technical they never promised a lack of system reboots. Maybe the new patch comes with features that ensure you're always running the latest kernel. You know getting all those Linux sysadmins who insist they don't need to reboot after applying security updates. ;-)
The Cortex-A75 is vulnerable according to ARM's own documentation.
While my opinion of intel is in the dump now, I can't honestly say it was truly incompetent.
It wasn't incompetent, it was unscrupulous. They did it wrong, and told everyone they were doing it right. They knew what they were doing, and furthermore, they knew it compromised security. It's not that Intel can't do it right. It's that Intel will lie to you and play games with the security of your data.
One reason Boeing makes such good airplanes is that WWII taught them every way to make a mistake.
In computer terms, WWII was way back around the 486 or the Pentium. Now we're into the global terrist threat phase of computer security, and Intel is still acting like it's WWII and cutting some corners to defeat the Wehrmacht is perfectly reasonable, but in this simile Intel is America, and is actually selling fuel and other war supplies to the Axis while the war is going on, and after finding out about the holocaust. Meanwhile, AMD is the UK, and if we can't keep those protections in our society (CPU) then what are we fighting for, anyway?
But shouldn't they be on the hook not for damages but at least the value of the computer itself as an upper bound.
Intel played fast and loose with your security in order to gain the upper hand in a marketing war, for no reason other than to make more profit. Making excuses for them is the ultimate victim behavior.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"