[openssl-users] request for TLBleed information / non-constant-time vulnerabilities

[Michael R. Hines]

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:
>> https://www.vusec.net/wp-content/uploads/2018/07/tlbleed-author-
>> preprint.pdf
> 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 
OpenSSL?

- Michael