Load Value Injection (CVE-2020-0551 and CVE-2020-0550)

General Privacy & Security
1

CPUs used by Librem servers are affected by both vulnerabilities, CPUs used by Librem laptops and Mini are affected by the first:


Is a mitigation available for Librem products and how much the impact on performance?
Last month Phoronix tested on Xeon a huge impact till 77%:
https://www.phoronix.com/scan.php?page=article&item=lvi-attack-perf&num=1

2

Sigh.

For the benefit of other readers:

CVE-2020-0550

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-0550

Improper data forwarding in some data cache for some Intel Processors may allow an authenticated user to potentially enable information disclosure via local access. The list of affected products is provided in intel-sa-00330: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00330.html

CVE-2020-0551

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-0551

Load value injection in some Intel Processors utilizing speculative execution may allow an authenticated user to potentially enable information disclosure via a side channel with local access. The list of affected products is provided in intel-sa-00334: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00334.html

The Debian web site https://security-tracker.debian.org/tracker/CVE-2020-0550
notes, in respect of 0550, Intel is (currently) no planning to release microcode updates to mitigate issue.

and provides additional reading.

As these attacks require local access, they are most likely to be of concern to people operating servers that allow multiple users to access, I suppose.

1 Like
3

I’ve not read the details on these, but do note that “local access” often includes javascript running in a browser.

5 Likes
4

Yes, I wondered about that too. I didn’t see info about whether either Intel bug would be exploitable from JavaScript.

1 Like
5

So, ostensibly, the answer is no… After all, these sorts of attacks generally require a high precision timer, which JS in the browser no longer provides. In practice, it’s a bit more complex. You can start a webworker (secondary JS thread), which can busy-wait to provide your high precision timer. The good news is that will load down a CPU core, so it’s somewhat lightly to get detected. The bad news is, thanks to “push notifications”, a compromised website could launch this attack while you’re not even connected to it.

There are mitigations, like not JIT compiling JS to native code, adding a random number of no-ops to loop controls so that busy-waiting timers become unreliable, and so on. They all have substantial performance impact though.

How any of that plays out with these two issues in particular is hard to say, it often takes a while to figure out how to get a particular JS engine to emit the right JITed code for these sorts of attacks.

2 Likes
6

I still need to take a look at this more closely, but my initial take from the deep dives linked by Intel:

Because malicious adversaries have limited ability to influence the paging behavior of victim processes to cause faults or assists in non-SGX environments, LVI is not a practical exploit in real-world non-SGX environments.

Purism doesn’t enable SGX (software guard extensions) in any of our coreboot-based firmware, so practically speaking, I don’t see it being an issue. It’s not something that can be enabled after boot either.

4 Likes
7

In such a case should we not mitigate both vulnerabilities in order to maintain CPU performance?

8

That question probably isn’t very well worded. Initially I read it as the exact opposite of what you probably intended.

To elaborate on the comment about SGX … SGX assumes that even the operating system is malicious. A malicious operating system can easily exploit this Intel CPU bug - and thereby potentially bypass what SGX is trying to achieve. However if the operating system is malicious, you and I wouldn’t be using Linux at all. Right? We would have much bigger problems than whether SGX is broken.

However if the last 12 months or so has taught us anything, I would NOT take Intel’s word that “LVI is not a practical exploit in real-world non-SGX environments” as gospel. It may alternatively mean simply that noone has yet come up with a smart enough exploit. For something that has only been in the wild for a few weeks, give the security researchers some time …

9

My concerns are: Intel disclosed two vulnerabilities, then it already released mitigations, such mitigations impact a lot on performance, so my idea is that vulnerabilities are more dangerous than what Intel is commenting now.
My questions are: will mitigations be available for Purism products too?
Are vulnerabilities so dangerous for Purism products too?
If vulnerabilities are not so dangerous for Purism products, then I should not mitigate them in order to maintain performance.

10

I don’t think that’s right.

For -0550 Intel says: Intel is not recommending any new or additional mitigations for Operating Systems.

For -0551 Intel says:

To mitigate the potential exploits of Load Value Injection (LVI) on platforms and applications utilizing Intel SGX, Intel is releasing updates to the SGX Platform Software (PSW) and SDK starting today.

Intel is not currently aware of any load value injection-specific universal or non universal gadget for [other environments] and is not releasing additional mitigations for these environments.

So if you take Intel’s word for it and you are not using SGX (and @MrChromebox has already stated that Purism platforms don’t use SGX) then … nothing to do … but in any case you are on your own for mitigations (nothing from Intel).