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
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
