[openssl-users] request for TLBleed information / non-constant-time vulnerabilities
Michael R. Hines
mrhines at digitalocean.com
Fri Jul 27 13:48:25 UTC 2018
On 07/27/2018 08:35 AM, Michael Wojcik wrote:
>> Our team is trying to get an accurate understanding of whether or not
>> cryptographic libraries are vulnerable to the kind of non-constant-time
>> attack used by exploits such as the one recently documented here:
> That's easy: Yes. The attack in the published paper is against a cryptographic library (libgcrypt), so at least one cryptographic library is vulnerable.
> More generally, TLBleed is not a software vulnerability, and as far as I'm aware no practical software mitigations have been shown for it. Therefore cryptographic libraries, like all other software, are vulnerable.
> The TLBleed authors note that their specific attack can be prevented by disabling hyperthreading (a system configuration mitigation), or by aggressively partitioning the target process address space (which would require massive code changes and would probably not be feasible for libraries, or for most applications). Beyond that we have only the usual mitigating factors: the attacker must be local and the attack requires substantial effort.
> (I'm only commenting on TLBleed here because I'm not sure what you mean by "non-constant-time attack". TLBleed isn't a timing side channel, so what does constant time have to do with the question?)
Hi Michael. Thanks for your response!
The paper is in fact based on a timing attack. Both Intel (and a nice
blog from Redhat) confirm this; In fact that's the only way this
particular vulnerability works. It leaks bits by observing the branch
path of the code referencing each bit while processing a private key
based on the time it takes to hit/miss a lookup in the TLB. If the
cryptographic implementation is constant-time, then the bits are not
discoverable and the attack is then unavailable.
We're trying to decide if we can avoid disabling hyperthreading, as our
measurements show that the performance losses (even with integer
workloads) are significant.
Might anyone be able to comment on this particular type of attack in
More information about the openssl-users