Spectre Meltdown

title: “Spectre and Meltdown Attacks against OpenSSL”
date: 2022-05-13 00:00
author: “OpenSSL Technical Committee”

published: true

The OpenSSL Technical Committee (OTC) was recently made aware of
several potential attacks against the OpenSSL libraries which might
permit information leakage via the Spectre attack.1 Although there
are currently no known exploits for the Spectre attacks identified,
it is plausible that some of them might be exploitable.

Local side channel attacks, such as these, are outside the scope of
our security policy, however the project generally does introduce
mitigations when they are discovered. In this case, the OTC has decided
that these attacks will not be mitigated by changes to the OpenSSL
code base. The full reasoning behind this is given below.

The Spectre attack vector, while applicable everywhere, is most important
for code running in enclaves because it bypasses the protections offered.
Example enclaves include, but are not limited to:

CCA
SEV
SGX

The reasoning behind the OTC’s decision to not introduce mitigations
for these attacks is multifold:

Such issues do not fall under the scope of our defined security policy.
Even though we often apply mitigations for such issues we do not mandate
that they are addressed.
Maintaining code with mitigations in place would be significantly more
difficult. Most potentially vulnerable code is extremely non-obvious,
even to experienced security programmers. It would thus be quite easy
to introduce new attack vectors or fix existing ones unknowingly.
The mitigations themselves obscure the code which increases the
maintenance burden.
Automated verification and testing of the attacks is necessary but
not sufficient. We do not have automated detection for this family
of vulnerabilities and if we did, it is likely that variations would
escape detection. This does not mean we won’t add automated checking
for issues like this at some stage.
These problems are fundamentally a bug in the hardware. The software
running on the hardware cannot be expected to mitigate all such attacks.
Some of the in-CPU caches are completely opaque to software and cannot
be easily flushed, making software mitigation quixotic. However, the OTC
recognises that fixing hardware is difficult and in some cases impossible.
Some kernels and compilers can provide partial mitigation.
Specifically, several common compilers have introduced code generation
options addressing some of these classes of vulnerability:

GCC has the -mindirect-branch, -mfunction-return and -mindirect-branch-register options
LLVM has the -mretpoline option
MSVC has the /Qspectre option

“Axiomatic Hardware-Software Contracts for Security,” in
Proceedings of the 49th ACM/IEEE International Symposium on Computer
Architecture (ISCA), 2022.

Nicholas Mosier, Hanna Lachnitt, Hamed Nemati, and Caroline Trippel,↩OpenSSL BlogRead More