Class-Action Lawsuit Forming Against Intel for 'Downfall' Chip Bug

News
By Francisco Pires
published

Tallying up damages and compensation.

Intel Alder Lake
(Image credit: Tom's Hardware)

Intel may soon find itself with its back against a proverbial wall following the disclosure of the "Downfall" chip vulnerability earlier this month. According to a class action aggregator, there's now an open interest in pursuing a lawsuit against Intel for damages relating to the Downfall vulnerability. That isn't surprising, given that fixing the bug can result in up to 39% less performance in some workloads and impacts what could number in the billions of processors. Called by law firm Bathaee Dunne LLP, the class action investigation (which is still garnering interest, plaintiffs, and information) aims to force Intel to compensate customers for "the loss of value, reduced performance, security issues and other damages stemming from the Downfall vulnerability."

Intel's Downfall is another high-impact, difficult-to-mitigate vulnerability that attacks speculative execution — a feature of modern CPUs that aims to predict what data and/or operations will be necessary for a workload to be completed before the information is even required. Speculative execution thus aims to keep that information readied and easily accessible for processing. Still, as the amount of vulnerabilities in speculative execution scenarios increases, we've also seen a trend where fixing these issues has a correspondingly negative impact on performance. For now, it appears Intel's mitigations for Downfall have an average performance cost around the 39% mark. 

Intel itself said performance could decline by as much as 50% in certain scenarios, showcasing just how important speculative execution is for a modern CPU's performance. Considering how the vulnerability affects Intel processors ranging from 6th-gen (Skylake) to 11th-gen (Rocket Lake), including Xeon products based on the same architectures, the amount of affected Intel CPUs will likely be in the billions. 

The argument for the class action lawsuit stems from the fact that affected users (like Intel) are left between a rock and a hard place: They paid 100% of a CPU's cost (which, in Intel's lineup, translates into an expected performance). But now, users have to choose between leaving their systems vulnerable to the Downfall speculative execution attack (not good) or taking a substantial hit to performance on workloads that matter to them (not great, either).

But in this case, keeping the vulnerability unaddressed could have a real impact on businesses and users. According to security researcher Danial Moghimi (who initially disclosed Downfall), the vulnerability would allow malicious third-party apps and services to steal sensitive information, including passwords, financial details, and even cloud-stored data.

Considering how AMD also has had its fair share of vulnerabilities (such as Inception, Squip, and its recent "Divide by zero" bug), it remains to be seen whether something similar will be aiming for the red team's bottom line as well.

Francisco Pires
Francisco Pires
Freelance News Writer

Francisco Pires is a freelance news writer for Tom's Hardware with a soft side for quantum computing.

24 Comments Comment from the forums
  • InvalidError
    Most of these side-channel attacks are purely theoretical yet practically impossible to achieve under real-world conditions where systems are juggling tens of thousands of threads spanning dozens of unrelated background processes, applications, system services, etc. and there are no guarantees that the desired data is in-flight through the victim algorithm at any particular time for the attack code to get anything back from.

    Since all of those side-channel attacks require extensive CPU-time abuse to even have a chance of succeeding, a successful exploit also requires failure to catch rogue processes consuming a disproportionate amount of CPU time that should cause performance complaints along with a substantial increase in system power draw.

    Most systems don't handle data anywhere near sensitive enough to worry about these. For environments where hypothetical side-channel attacks are unacceptable, we'll need different CPUs designed specifically to eliminate all potential crosstalk between unrelated threads.

    For most other uses, all that is really necessary would be to provide software developers with the ability to mark security-critical parts of their software to prevent unrelated code from running on the same CPU/L2 until it exits the protected section - can't side-channel-attack code when you cannot run concurrently.
    Reply
  • abufrejoval
    Resilience against side channel attack is not a quality that was sold, so I don't see a logical base for getting damage compensation.

    But juries vote and do not deduct, so who knows where this is going. It won't help if CPU makers were completely driven out of business.

    Verifiying a speculative design to have no side vulnerabilities seems theoretically impossible because it sounds very much like an Emil Post correspondance problem, "reasonable assurance" still neigh unaffordable.

    Without all those speculation tricks CPUs can only go wide like GPU cores and that means that without a massive rewriting of all code speeds will badly disappoint.

    This will drive a large performance and technology wedge between designs that don't need to care about side channels, because they are not shared and others that potentially share resources.

    If speculation can be activated on the fly so that certain code passsages can be excluded, or if caching domains can be segregated more carefully, that's also something that might help in cloudy scenarios.

    But being successfully sued for something nobody asked you to design for, should be reserved for very exceptional cases.
    Reply
  • Francisco Alexandre Pires
    InvalidError said:
    Most of these side-channel attacks are purely theoretical yet practically impossible to achieve under real-world conditions where systems are juggling tens of thousands of threads spanning dozens of unrelated background processes, applications, system services, etc. and there are no guarantees that the desired data is in-flight through the victim algorithm at any particular time for the attack code to get anything back from.

    abufrejoval said:
    Resilience against side channel attack is not a quality that was sold, so I don't see a logical base for getting damage compensation.


    It seems to me (and please correct me if I'm wrong) that you are conflating "speculative execution" with "side-channel attacks".

    While most side-channel attacks sniff information that exists and is exposed Because of speculative execution, they are different things. Not all speculative execution vulnerabilities are explored via side-channel attacks; in the case of Downfall, the issue is that sensitive information is available through other means other than side-channel attacks (certain software can access speculative information left within caches and registers with no need for a "side-channel" approach).

    So while protection from "side-channel attacks" may be debatable from a responsibility standpoint (which you both address), "insecure" speculative execution that's used to increase a processor's performance IS a feature (because it contributes to the processor's performance and your expectation of performance).

    In this case, it's not only a feature, but it's a bugged one. And Intel did promise a working product with a certain performance profile. I don't yet have a strong opinion on this, but it seems to me that Intel is responsible for ensuring its speculative execution features (which give its CPUs performance characteristics that sometimes lead them to be the best option in the market when final performance is accounted for) are airtight (within reason).

    Perhaps Intel and AMD would be better-off by adding a small line to their already immense "T&C" adding that "the dynamic nature of cybersecurity means that mitigations can alter your CPU's performance profile, and its current performance should be viewed as a best-case scenario and not representative of future performance".
    Reply
  • RichardtST
    Well, here's the real problem... If you start allowing damages against bugs, then the entire hardware and software industries shut down. Poof. Gone. No more hardware. No more software. The complexity of them both is to such a degree that it is, at this point, impossible to not have a number of fatal flaws. Just not gonna happen. The buyer has to accept the risk, otherwise they get nothing.
    Reply
  • InvalidError
    Francisco Alexandre Pires said:
    It seems to me (and please correct me if I'm wrong) that you are conflating "speculative execution" with "side-channel attacks".
    Because it is a side-channel: Downfall poses no threat at all without malicious code somewhere else actively attempting to scoop whatever data it may be leaking and successfully extracting data still requires the attacking thread to get lucky with peeking at what it can see while relevant data is being processed and attempt to infer the target content from it. No plain-text user-space data is being directly leaked.

    RichardtST said:
    Well, here's the real problem... If you start allowing damages against bugs, then the entire hardware and software industries shut down.
    You do want to allow accountability for bugs that make a product fundamentally unsuitable for its intended purposes like the Pentium FP bug that made affected FPUs effectively worthless.

    Mostly hypothetical security bugs like Downfall and Heartbleed don't really affect anyone besides people who run high-security applications on x86 hardware and if you run such stuff, you should be closely monitoring your systems for unidentified processes as your fourth line of defence after strict firewalling, strict access control lists and skimming logs for suspicious connection/login attempts for preemptive action.
    Reply
  • ravewulf
    To my knowledge, they never claimed it would be completely bug-free and it's simply not possible to predict how much of a performance impact an unknown future mitigation is going to cost. At best, you could give a worst case for performance if you completely disable speculative execution but that's still leaving unknown variables on the table. So, yeah, it sucks that you have to choose between maximum security vs the original performance but what would be the reasonable alternative?
    Reply
  • hotaru251
    imho Intel will likely fallback on the unknown attacks in future of a product as its beyond their scope of knowing as attacks and the like change every day.
    Reply
  • InvalidError
    ravewulf said:
    So, yeah, it sucks that you have to choose between maximum security vs the original performance but what would be the reasonable alternative?
    If you need the highest security possible, don't allow your security-critical code and services to run on a machine that also runs arbitrary user code such as a virtualized server instance. If you don't allow any unknown code on your security-critical servers, side-channel exploits are irrelevant.
    Reply
  • Francisco Alexandre Pires
    InvalidError said:
    Because it is a side-channel: Downfall poses no threat at all without malicious code somewhere else actively attempting to scoop whatever data it may be leaking and successfully extracting data still requires the attacking thread to get lucky with peeking at what it can see while relevant data is being processed and attempt to infer the target content from it. No plain-text user-space data is being directly leaked.


    You do want to allow accountability for bugs that make a product fundamentally unsuitable for its intended purposes like the Pentium FP bug that made affected FPUs effectively worthless.

    That doesn't sound right to me. Correct me: it seems to me that from that perspective, everything is a side-channel attack, because everything else still needs an external event/code injection/enabler in order to steal the target data, whether it's plain-text or not. I know I'm on the "wrong side" of the fence here, but I need to think and read more about this.

    In this case, I think the deeper question comes from the fact that performance after the patch will no longer be representative of the initial performance claims/benchmarks. In that sense, customers see a performance regression that has nothing to do with how they use the product, but which has everything to do with the (bugged) features Intel (and others) build into their products.


    RichardtST said:
    Well, here's the real problem... If you start allowing damages against bugs, then the entire hardware and software industries shut down. Poof. Gone. No more hardware. No more software. The complexity of them both is to such a degree that it is, at this point, impossible to not have a number of fatal flaws. Just not gonna happen. The buyer has to accept the risk, otherwise they get nothing.

    Fully agreed. There's inherent risk, and that risk has to be accepted. But still it seems like a case-by-case review is at least necessary.

    Then again, someone in the US was awarded $800,000 because McDonald's McNuggets were so hot they burned a child. Here, the responsibility for making sure that nuggets were at an adequate temperature was understood to lie not with the parent, nor with the child, nor with "common sense and attention", but with the corporation itself. Doesn't sound right to me, but it does say something about lawsuits and the current legal understanding of "responsibility".

    If companies want to protect themselves, they apparently have to pre-emptively work by making sure that "expectations" are aligned with reality. In this case, it seems that a TC update along the lines of what I posted above might help.
    Reply
  • domih
    RichardtST said:
    Well, here's the real problem... If you start allowing damages against bugs, then the entire hardware and software industries shut down. Poof. Gone. No more hardware. No more software. The complexity of them both is to such a degree that it is, at this point, impossible to not have a number of fatal flaws. Just not gonna happen. The buyer has to accept the risk, otherwise they get nothing.
    It depends. I believe it has to be on a case per case basis. As it is today.

    See for instance the MoveIt disaster (https://www.darkreading.com/search?q=MoveIt), all these consequences for a stupid SQL injection. IMHO, software makers should be held responsible for NOT preventing SQL injections.

    Car makers have been sued for defects and car makers are still making cars.
    Reply