Intel's "DOITM" Security Feature Not Intended For Always-On Use, Linux Patches To Be Revised

[hotaru]

There are plenty of machines out there with multiple users accessing them concurrently.

any machine that runs a web browser has multiple users accessing it concurrently: the obvious one, plus everyone who's ever touched any of the JS running in that web browser.

this vulnerability can also affect single-user machines, because it creates timing side channels in things like NSS and OpenSSL which can be observed over a network.

[piotrj3]

The conceptual difficulty of an attack has very little bearing on the availability. People can (and do) create packages (metasploit modules, proof-of-concept scripts, etc) which make attacks accessible to a much wider audience.



Networks don't prevent timing side channel attacks; they only slow them down. Examples:

• Meltdown and Spectre were initially exploitable remotely
• Cache Timing Attacks on AES (PDF. Daniel J Bernstein, 2005): AES private key recovery over the network via a cache timing side channel attack. Note: This attack has been improved since the original 2005 paper, and most software-only AES implementations are vulnerable.

1st article has nothing to do with network attack. It is basicly webrowser executing code that could be meltdown/spectre sensitive. Also it is not true they were initially exploitable by webrowser (it took few months of working by google project zero to make spectre demo working in webrowser) it was mostly manually crafted assembly. By network attack i mean you ask server with packet about something and depending on content/key etc you have diffrent time of response. Notice webrowser to protect themselves used 20us, this is extremly small in context of networking making such attack impractical.

2nd. Very old article and almost no modern AES implementation use those guidelines.

3rd. Yes i know metasploit, in fact i use it commercially as i am pentester myself.

Most spectre/meltdown attacks rely on timers, 5us is not that hard, 20us is hard, 100us is very hard to do it. From perspective of networking delay (unstability) even 100us is extremly short time. And that assumes you are on the same local network, if you try to do it over internet, F... good luck.

Again i believe in webrowsers it makes sense to use DOITM. But question is how big diffrence (timing wise) is between best case scenario and worst case scenario. If diffrence is again most of time is extremly short, it might not matter.

[hotaru]

Again i believe in webrowsers it makes sense to use DOITM. But question is how big diffrence (timing wise) is between best case scenario and worst case scenario. If diffrence is again most of time is extremly short, it might not matter.

the problem is that all the other software that might run at the same time as the web browser needs DOITM. the browser turning it on for itself won't do anything to prevent an attack running in the browser from observing timing differences that result from code outside the browser running in Intel's new on-by-default "fuck me" mode.

[piotrj3]

the problem is that all the other software that might run at the same time as the web browser needs DOITM. the browser turning it on for itself won't do anything to prevent an attack running in the browser from observing timing differences that result from code outside the browser running in Intel's new on-by-default "fuck me" mode.

If i understand correctly Intel's idea, i don't think this will be possible.

[hotaru]

If i understand correctly Intel's idea, i don't think this will be possible.

it's not possible without leaving DOITM enabled all the time. it can't work any other way.

[Developer12]

1st article has nothing to do with network attack. It is basicly webrowser executing code that could be meltdown/spectre sensitive. Also it is not true they were initially exploitable by webrowser (it took few months of working by google project zero to make spectre demo working in webrowser) it was mostly manually crafted assembly. By network attack i mean you ask server with packet about something and depending on content/key etc you have diffrent time of response. Notice webrowser to protect themselves used 20us, this is extremly small in context of networking making such attack impractical.

2nd. Very old article and almost no modern AES implementation use those guidelines.

3rd. Yes i know metasploit, in fact i use it commercially as i am pentester myself.

Most spectre/meltdown attacks rely on timers, 5us is not that hard, 20us is hard, 100us is very hard to do it. From perspective of networking delay (unstability) even 100us is extremly short time. And that assumes you are on the same local network, if you try to do it over internet, F... good luck.

Again i believe in webrowsers it makes sense to use DOITM. But question is how big diffrence (timing wise) is between best case scenario and worst case scenario. If diffrence is again most of time is extremly short, it might not matter.

The issue at hand has nothing to do with spectre.

If you are a competent security professional, you should know that there's a damn good reason security-critical code (including that for AES) is written to be constant time. Doing so fundamentally requires operations like addition and bitwise comparison to be constant time, which this optimization strongly violates.

You should also know that there have been hundreds of CVEs files for code that should have been constant time not having been written as such, causing very network-observable delays and severe vulnerabilities. We are not talking about small timing delays like a cache hit or miss here. Checking a 20-character password and bailing out early has an enormous effect on timing that can be observed far over the internet.

These optimizations are intentionally designed to create large, observable timing differences because that is how they measurably improve performance.

[Developer12]

the problem is that all the other software that might run at the same time as the web browser needs DOITM. the browser turning it on for itself won't do anything to prevent an attack running in the browser from observing timing differences that result from code outside the browser running in Intel's new on-by-default "fuck me" mode.

at the bare minimum, this optimization needs to be available per-thread. then the high-performance guys can turn it on and get their extra 5% without fucking everyone else over.

[yump]

These optimizations are intentionally designed to create large, observable timing differences because that is how they measurably improve performance.

Good point.

[pabs]

1st article has nothing to do with network attack. It is basicly webrowser executing code that could be meltdown/spectre sensitive.

Web browsers were initially vulnerable to Meltdown and Spectre; in other words, a person using a browser to view a malicious web site over a network which contained specially-crafted JavaScript would cause the browser to leak protected memory and allow it to be exfiltrated. From A Spectre proof-of-concept for a Spectre-proof web (2021):

In this post, we will share the results of Google Security Team's research on the exploitability of Spectre against web users, and present a fast, versatile proof-of-concept (PoC) written in JavaScript which can leak information from the browser's memory. We've confirmed that this proof-of-concept, or its variants, function across a variety of operating systems, processor architectures, and hardware generations.

The article linked above also includes a video demonstration of the proof-of-concept, if anyone is interested.

Also it is not true they were initially exploitable by webrowser (it took few months of working by google project zero to make spectre demo working in webrowser) it was mostly manually crafted assembly. By network attack i mean you ask server with packet about something and depending on content/key etc you have diffrent time of response. Notice webrowser to protect themselves used 20us, this is extremly small in context of networking making such attack impractical.

Browsers were initially vulnerable to Meltdown and Spectre. It may have taken time for security researchers to release a viable proof-of-concept, but that is a separate issue.

2nd. Very old article and almost no modern AES implementation use those guidelines.

Recent versions of OpenSSL still include a non-constant-time reference implementation of AES. See this commit and this entry in CHANGES.md for OpenSSL 3.0.2 from March 2022. This particular implementation is not enabled by default on most platforms and you have to go out of your way to enable it, but it is still possible for a package maintainer or user to do so by mistake.

The paper is from 2005, but timing side channel attacks against AES are still relevant and have been refined over time. Here is a paper from 2016 which improves the attack: Highly Efficient Algorithms for AES Key Retrieval in Cache Access Attacks.

I linked to the original 2005 paper rather than a newer version because the original paper includes a good explanation of the following:

1. Common pitfalls when writing a software-only implementation of AES.
2. Why adding noise does not prevent timing side channel attacks (see below).

If folks are interested, the fundamental problem here is AES itself: the design encourages unsafe (non-constant-time) implementations. This is true of any algorithm which uses S-boxes or any other mechanism which does variable-time calculations with secret data.

Newer algorithms like ChaCha20 and Curve25519 are specifically designed to avoid timing side channel implementation pitfalls, and resistance to timing side channel attacks is an important consideration for candidates in the NIST Post-Quantum Cryptography Standardization Process.

For example, the round 3 Dilithium submission includes an entire section (5.5) talking about their constant-time reference implementation:

Our reference implementation does not branch depending on secret data and does not access memory locations that depend on secret data.

Most spectre/meltdown attacks rely on timers, 5us is not that hard, 20us is hard, 100us is very hard to do it. From perspective of networking delay (unstability) even 100us is extremly short time. And that assumes you are on the same local network, if you try to do it over internet, F... good luck.

Adding network jitter does not prevent timing side channel attacks, it only slows them down. This excerpt from the from the Cache-timing attacks on AES paper explains why (emphasis mine):

Of course, I wrote this server to minimize the amount of noise in the timings
available to the client. However, adding noise does not stop the attack: the client
simply averages over a larger number of samples, as in [7]. In particular, reducing
the precision of the server’s timestamps, or eliminating them from the server’s
responses, does not stop the attack: the client simply uses round-trip timings
based on its local clock, and compensates for the increased noise by averaging
over a larger number of samples.

[bavay]

So, managing your memory yourself (with alloc / free) is slowly getting close to extinct. There was nothing wrong with that, just that humans do mistakes and tended to forget to call *free* or used the pointer after they had called *free*, etc Now Intel is coming with a replacement concept: you should set / unset an proprietary Intel register when you do security critical code. What do you think will happen? Most of the software will forget to unset the register, degrading the performance of everything that runs after them. Most will also forget to set the register in some code paths, leading to side channel attacks. Most software will most probably see a combination of both.

Hopefully, 20 years from now a new language will emerge that manages this setting / unsetting of registers automatically for you (we will call it "Intel's trash collector").

As somebody above said, this would be fine if per thread and opt-in by default: optimization sensitive code could set it to benefit from (minor) optimizations while the rest of the code (and more importantly all other threads and processes) would remain safe by default.