New Working Speculative Execution Attack Sends Intel and AMD Scrambling (arstechnica.com) 66
Some microprocessors from Intel and AMD are vulnerable to a newly discovered speculative execution attack that can covertly leak password data and other sensitive material, sending both chipmakers scrambling once again to contain what is proving to be a stubbornly persistent vulnerability. Ars Technica reports: Researchers from ETH Zurich have named their attack Retbleed because it exploits a software defense known as retpoline, which was introduced in 2018 to mitigate the harmful effects of speculative execution attacks. Speculative execution attacks, also known as Spectre, exploit the fact that when modern CPUs encounter a direct or indirect instruction branch, they predict the address for the next instruction they're about to receive and automatically execute it before the prediction is confirmed. Spectre works by tricking the CPU into executing an instruction that accesses sensitive data in memory that would normally be off-limits to a low-privileged application. Retbleed then extracts the data after the operation is canceled. [...] The ETH Zurich researchers have conclusively shown that retpoline is insufficient for preventing speculative execution attacks. Their Retbleed proof-of-concept works against Intel CPUs with the Kaby Lake and Coffee Lake microarchitectures and AMD Zen 1, Zen 1+, and Zen 2 microarchitectures.
In response to the research, both Intel and AMD advised customers to adopt new mitigations that the researchers said will add as much as 28 percent more overhead to operations. [...] Both Intel and AMD have responded with advisories. Intel has confirmed that the vulnerability exists on Skylake-generation processors that don't have a protection known as enhanced Indirect Branch Restricted Speculation (eIBRS) in place. "Intel has worked with the Linux community and VMM vendors to provide customers with software mitigation guidance which should be available on or around today's public disclosure date," Intel wrote in a blog post. "Note that Windows systems are not affected given that these systems use Indirect Branch Restricted Speculation (IBRS) by default which is also the mitigation being made available to Linux users. Intel is not aware of this issue being exploited outside of a controlled lab environment." AMD, meanwhile, has also published guidance. "As part of its ongoing work to identify and respond to new potential security vulnerabilities, AMD is recommending software suppliers consider taking additional steps to help guard against Spectre-like attacks," a spokesman wrote in an email. The company has also published a whitepaper.
[Research Kaveh Razavi added:] "Retbleed is more than just a retpoline bypass on Intel, specially on AMD machines. AMD is in fact going to release a white paper introducing Branch Type Confusion based on Retbleed. Essentially, Retbleed is making AMD CPUs confuse return instructions with indirect branches. This makes exploitation of returns very trivial on AMD CPUs." The mitigations will come at a cost that the researchers measured to be between 12 percent and 28 percent more computational overhead. Organizations that rely on affected CPUs should carefully read the publications from the researchers, Intel, and AMD and be sure to follow the mitigation guidance.
In response to the research, both Intel and AMD advised customers to adopt new mitigations that the researchers said will add as much as 28 percent more overhead to operations. [...] Both Intel and AMD have responded with advisories. Intel has confirmed that the vulnerability exists on Skylake-generation processors that don't have a protection known as enhanced Indirect Branch Restricted Speculation (eIBRS) in place. "Intel has worked with the Linux community and VMM vendors to provide customers with software mitigation guidance which should be available on or around today's public disclosure date," Intel wrote in a blog post. "Note that Windows systems are not affected given that these systems use Indirect Branch Restricted Speculation (IBRS) by default which is also the mitigation being made available to Linux users. Intel is not aware of this issue being exploited outside of a controlled lab environment." AMD, meanwhile, has also published guidance. "As part of its ongoing work to identify and respond to new potential security vulnerabilities, AMD is recommending software suppliers consider taking additional steps to help guard against Spectre-like attacks," a spokesman wrote in an email. The company has also published a whitepaper.
[Research Kaveh Razavi added:] "Retbleed is more than just a retpoline bypass on Intel, specially on AMD machines. AMD is in fact going to release a white paper introducing Branch Type Confusion based on Retbleed. Essentially, Retbleed is making AMD CPUs confuse return instructions with indirect branches. This makes exploitation of returns very trivial on AMD CPUs." The mitigations will come at a cost that the researchers measured to be between 12 percent and 28 percent more computational overhead. Organizations that rely on affected CPUs should carefully read the publications from the researchers, Intel, and AMD and be sure to follow the mitigation guidance.
My potato is unaffected (Score:5, Informative)
The AMD Security Bulletin âAMD-SB-1037 [amd.com] regarding CVE-2022-23825 (Branch Type Confusion) states that only them fancy new Ryzen CPUs and the like are affected, not my antique AMD FX chip. I'm also not vulnerable to CVE-2022-29900 (RETbleed) which affects "AMD microprocessor families 15h to 18h", my Vishera is a 21. I successfully avoided needing expensive mitigation by not having any performance to begin with.
Re: (Score:3)
Hmm, It just occurred to me to wonder if my family was being given in hex or dec. Sadly, linux displays it in decimal, but AMD uses hex. I appear to have RETbleed mitigations enabled, however.
Re: (Score:2)
If you ever get a new potato, you may need this [sleeplessbeastie.eu].
I bought 100% of a CPU, I want 100% of its capabilities and performance.
Re: (Score:2)
That's like saying you bought a new car and don't want to pay the weight penalty to drive around with seat belts, air bags, tempered glass windows, high-center brake light, etc.
OK, you can strip all the Spectre and other security measures from your build, but please don't connect your system to the internet afterward. We really don't need another drone in a botnet to attack the rest of us. Being part of a social group implies a little bit of personal discomfort for the benefit of the larger group.
Yeah, ye
Re: (Score:2)
Re: My potato is unaffected (Score:2)
It depends on the description of the goods. If the product's performance as advertised can no longer be achieved then that's an issue.
To use a car analogy, it may be more fitting to imagine a car, sold as a five seater, now reduced to four seats due to an aftermarket fix made for safety reasons.
Re: My potato is unaffected (Score:2)
Or a car sold with 250 horse power that only has 200 after a few years. Arenâ(TM)t horses expected to die in the engine over time and everyone accepts it?
For the EV car analogy that would be the range your battery provides dropping off after a few years.
Re: (Score:2)
Or a car sold with 250 horse power that only has 200 after a few years. ArenÃ(TM)t horses expected to die in the engine over time and everyone accepts it?
Not any more. Most engines can now produce way more power than they do on a day to day basis. That's why "tuning" can make most cars more powerful now even without any upgrades. One does generally expect to have to do a fuel injector service around 200k, but that can literally be as little as pulling the fuel rail and injectors, and putting new input basket filters in the injectors. (They should be tested, and it's smarter to replace them these days, injectors are usually cheap except for diesels.)
Re: My potato is unaffected (Score:2)
Sure, that can be an expected deterioration for a product of a component. Certainly braking performance will decrease with wear. CPUs aren't sold with the expectation of declining performance. Assuming the CPU is operated within electrical and thermal specifications, it should continue to meet or exceed its specified performance until there's a hardware failure. The extent to which this becomes a legal issue depends on law pertaining to sale and any performance claims made by the seller. Weasel 'up to' clai
Re:My potato is unaffected (Score:5, Insightful)
I successfully avoided needing expensive mitigation by not having any performance to begin with.
I successfully avoided needing expensive mitigation by doing a risk assessment and realising that despite speculative execution problems remaining largely unpatched across systems and servers the world over there have been precisely zero practical cases of it being exploited in the wild.
If you have enough knowledge to extract specific password / encryption key information via speculative execution, chances are you're already using my machine, or it's sitting on your desk in your lab.
Re: (Score:3)
Whilr a vulnerability like this might be only theoretically exploitable to extract a password from a running desktop, in more standardized environments like IoT devices, network equipment and the like, which run a standard imag
Re: (Score:2)
Possibly. However equipment you talk about running x86 based systems almost universally don't have a standard memory layout on modern systems, and ancient systems aren't vulnerable to speculative execution. Mitigations such as ASLR have been a default for a long time (except for FreeBSD where it was disabled by default until embarrassingly recently) and have been available in general for 2 decades now.
Re: (Score:2)
That is basically the gi
I'm not too worried, (Score:5, Funny)
they're just speculating.
Re: (Score:2)
"Sends them scrambling". But does it though? (Score:5, Insightful)
This sounds like another one of those exploits that only works in a lab-controlled environment where a single-process is running in near-ideal circumstances. But if you were AWS or Azure with stacks of docker containers all running, how likely is this sort of attack to yield anything usable?
I think there's a certain logic to saying "Yeah, you know what? We're willing to admit there's some miniscule chance for an attack in exchange for not losing 28% to overhead"
Re: (Score:3, Interesting)
Re:"Sends them scrambling". But does it though? (Score:4, Informative)
Well back in the day we made Intel recall millions of processors to fix a bug [wikipedia.org] that would effect performance on one in ten million processors once in its lifetime.
The floating point bug in the CPU did not affect just one in ten million processors. It affected every processor that was recalled. The chance of it happening is not the same as the odds of a processor being bad. From the very article you linked to:
Though rarely encountered by most users (Byte magazine estimated that 1 in 9 billion floating point divides with random parameters would produce inaccurate results), blah blah blah
Re:"Sends them scrambling". But does it though? (Score:4, Informative)
that would effect performance on one in ten million processors once in its lifetime.
No they didn't. They recalled a processor which would give an error on one in ten billion floating point operations. This bug basically affected anyone using their computer for serious and continuous calculation work (basically any kind of science or engineering). It was unlikely to affect a normal user... back in the day. These days floating point operations are critical and constantly performed by normal software and an identical error would almost certainly affect most customers.
You make a valid point IF this attack is actually unlikely to work in the real world. We don't know that yet.
Yes we do, the risk profile, execution and outcome of this attack is similar to the ones we've been talking about for the past 5 years. These are among the most widely known, well publicised, and largely unpatched security vulnerabilities in the world. Yet there's been precisely zero evidence of it ever being used outside of a controlled / well known environment.
If someone knows enough about your machine to execute these attacks, chances are that they are the machine admin already. Or your machine is sitting in their lab.
Re: (Score:2)
One important part of the "cloud" is the high degree of control they have of it. The only thing they don't have as much of is what their customers create.
Re: (Score:3)
Do not share CPUs! (Score:3)
If you are doing high security stuff on in the cloud or elsewhere, only your software should be running on a given CPU.
It is way to hard to really know whether there are leaks between processes.
Better, run it on a computer that you control and nothing else runs on.
Re:Do not share CPUs! (Score:4, Interesting)
Sure. But the PHBs have been successfully manipulated in thinking "the cloud" is the solution for everything. Just as before they have, for example, been manipulated in thinking MS makes good software, and look at the mess with endless vulnerabilities, botched patches, ransomware, productivity decreasing GUIs, excessively lying about the product strategy, etc. we have now.
Sure, you can do things securely in a cloud. But it has to be a private cloud, it has to be separated into security zones, CPUs need to be dedicated above certain security requirements, etc. And that is not something the typical cloud user can manage or even really understand.
Re: (Score:2)
Or, you could run it in an environment that actually takes security seriously, such as IBM Secure Execution for Linux [ibm.com]
Re: (Score:3)
Sure. But AWS or Azure cannot actually do much about this, except by the images they provide. As soon as the customer has their own images, they can only hope. They could try to work only with dedicated CPUs. But I think they are doing this mostly already.
Re: (Score:3)
To my mind the best approach is to have a system that has approved (signed?) binaries, and only those are allowed to operate without mitigations. Then you can have your security, and your performance. Just operating without mitigations is asking to be caught up in the first wave of a successful exploit.
Who does this impact? (Score:2)
I get some of the basics, but what systems or companies would be impacted by this? Where is this used in the wild? Why should I care?
Is this a way to leak Blu-Ray keys? Or passwords to a virus?
The penalties to execution speed look brutal. Is there a situation where it's worth losing 25-40% of your performance for security? I'd assume for most people it's not. I'd be happy with detecting something attempting that on my system...then I could clean or remove it.
And I saw a comment about Windows not being
cloud computing vendors may not give you that choi (Score:2)
cloud computing vendors may not give you that choice.
But if you have your own DC then you can set your VM HOSTS to bypass mode.
Donald Knuth is laughing in his tomb (Score:2, Interesting)
"Excess optimization is the root of all evil."
No, he's not (Score:3)
The lack of access controls on speculative execution was an explicit tradeoff.
Re: (Score:3)
Re: (Score:2)
Uh what? Is this some sort of Mandela effect? Knuth is still alive. Style working on a fascicle what are we up to now? fascicle 20?
Re:Donald Knuth is laughing in his tomb (Score:5, Funny)
Re: (Score:2)
And it's all about what is excess.
You can see the conflict. Some people are all "28%?! fuck that!" and some people are all "what about correctness?!" And it's cross-organizations. The same flaw in two mostly-ind
Re: (Score:2)
Any news of the same basic mistake on non-x86 archs? If not, why not?
Ones that don't use speculative execution.
Re: (Score:3)
Good answer. But I figured all the CPU designers would be moving toward speculative execution, for the same reason people are complaining about the performance costs of mitigation. People want things to be faster. (OTOH: things need to work correctly!)
Re: (Score:2)
I thought it was premature optimization.
Re:Donald Knuth is laughing in his tomb (Score:5, Informative)
1. Knuth is alive
2. That's not even the quote, it's "premature" optimization.
Re:Donald Knuth is laughing in his tomb (Score:5, Funny)
1. Knuth is alive
I wouldn't be so sure about that because reading the post that so badly misquoted him just may have killed him.
Re:Donald Knuth is laughing in his tomb (Score:5, Funny)
He just has a private tomb he likes to hang out and laugh in.
Re: (Score:2)
"Excess optimization is the root of all evil."
I'm okay with it. If a little evil is required for a super fast modern PC, let's do it. You go kill the bunny, I'll go kill the dog and then we'll laugh manically together at 4GHz.
Re: (Score:2)
Knuth is still alive. And it is "premature" optimization. Also does not refer to hardware design, Knuth did not do that.
Re: (Score:2)
Knuth is still alive. And it is "premature" optimization. Also does not refer to hardware design, Knuth did not do that.
Knuth designed the MIX computer and its successor, MMIX. He also wrote assemblers and simulators for them.
Re: (Score:2)
Knuth is still alive. And it is "premature" optimization. Also does not refer to hardware design, Knuth did not do that.
Knuth designed the MIX computer and its successor, MMIX. He also wrote assemblers and simulators for them.
Interesting. I was unaware of that. Did this actually make it to hardware?
Re: (Score:3)
Knuth is still alive. And it is "premature" optimization. Also does not refer to hardware design, Knuth did not do that.
Knuth designed the MIX computer and its successor, MMIX. He also wrote assemblers and simulators for them.
Interesting. I was unaware of that. Did this actually make it to hardware?
As far as I know there has never been a complete hardware implementation of MMIX, but there is a partial Verilog on GitHub with some insightful comments in the README files. See https://github.com/tommythorn/fpgammix [github.com].
Re: (Score:2)
As far as I know there has never been a complete hardware implementation of MMIX, but there is a partial Verilog on GitHub with some insightful comments in the README files. See https://github.com/tommythorn/fpgammix [github.com].
That would at least have allowed simulation. Thanks for the reference!
Re: (Score:2)
Thank you for the correction of the quote. The rule does apply to hardware as well as software.
Windows is more secure than Linux (Score:1)
> Note that Windows systems are not affected given that these systems use Indirect Branch Restricted Speculation (IBRS) by default which is also the mitigation being made available to Linux users
> Linux creator Linus Torvalds famously rejected such warnings, arguing that such exploits weren’t practical.
Ah, ha, ha, ha, ha, ha, ha
Re: (Score:2)
Hardware Diversity (Score:4, Interesting)
Part of the problem is we're using the same hardware to serve cat videos as for handling banking keys. "Just make everything secure" ignores the fact that this 28% extra processing does in fact use both physical and electrical resources.
"Oh, but you have to protect your root password and SSL certs". Yes. With the current architecture. The cat videos are chasing their tail.
It's dumb that we're still building IBM AT computers that go really fast to use for almost everything. Who's working on web-first sever architectures? Why don't we have control nodes with the equivalent of GPU's for squirting unicast down the wire?
Probably this will only happen in the RISC-V space. Smart VC's will put all this together.
Re:Hardware Diversity (Score:4, Interesting)
It's dumb that we're still building IBM AT computers that go really fast to use for almost everything.
You're either really smart and up to something, or drunk posting. I can't tell. With your UID, I'm gonna go with really smart, but let me propose an alternative/comparison. When is it enough of a deviation to satisfy "different needs"? Take, for instance, that almost every digital chip out there operates on the premise of a binary state. But there's no reason why we couldn't use technology that could store any combination of numbers in its smallest unit, i.e. a memory chip whose smallest storage unit could be any of 8 different states, instead of just 2. We could then have a whole industry around chips that operate that way. It would be expensive as a new technology and most people would just opt for binary computers. And you're back to the IBM AT architecture.
OTOH, maybe it's me who's drunk.
Re: (Score:3)
Part of the problem is we're using the same hardware to serve cat videos as for handling banking keys. "Just make everything secure" ignores the fact that this 28% extra processing does in fact use both physical and electrical resources.
Remember reading papers on exploiting processor side channels to extract private keys a decade before present day parade of named CPU exploits started.
At the time figured this was simply out of scope similar to RF/DPA side channels. Still believe that. Does not seem Intel CPUs were ever designed for the level of security people started assuming they could provide and it isn't reasonable to expect otherwise from them.
Yet I don't know why performance should necessary be linked to security. Seems likely tha
Re: (Score:2)
It's dumb that we're still building IBM AT computers that go really fast to use for almost everything. Who's working on web-first sever architectures?
Sun tried that. It was a senseless flop. RIP Sun.
Linux is running 12--28% slower than Windows now? (Score:2)
The mitigations will come at a cost that the researchers measured to be between 12 percent and 28 percent more computational overhead.
And
Note that Windows systems are not affected given that these systems use Indirect Branch Restricted Speculation (IBRS) by default which is also the mitigation being made available to Linux users.
Really?
Re: (Score:2)
And by "slower", I mean "faster".
IBRS (Score:5, Interesting)
From a comment on Ars Technica: "Intel wrote in a blog post. “Note that Windows systems are not affected given that these systems use Indirect Branch Restricted Speculation (IBRS) by default which is also the mitigation being made available to Linux users."
I wasn't aware of IBRS [intel.com], but it seems like this is the solution: be able to restrict speculation when it's important. Perhaps this should even be the default: speculation restricted (or disabled), unless specifically turned on. For most common scenarios, losing 15%-20% of the processor performance is utterly irrelevant. When you need speed, then you allow speculation - and the programmer needs to know if/when this is ok.
Re: (Score:2)
Given all the difficulties these kinds of exploits are causing, it's more like IBS [wikipedia.org], amirite?
Sorry, I'll see myself out now.
Re: (Score:2)
losing 15%-20% of the processor performance is utterly irrelevant.
Not for datacenters who's existence have become predicated on reducing electrical use/costs.
Many home potatoes are not affected (Score:1)
cloud computing and javascript (Score:2)
Re: (Score:2)
Unless you have firefox with noscript installed (or, like, links or something), you're running untrusted code just visiting here.
Dumb question here (Score:2)
Does Apple's M1 and M2 processors have similar vulnerabilities?
Re: (Score:2)
The broader class of "Spectre-style speculative execution sidechannels" is Yes. All speculative CPUs are. Period.