request for TLBleed information / non-constant-time vulnerabilities

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

request for TLBleed information / non-constant-time vulnerabilities

OpenSSL - User mailing list
Good afternoon,

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

Unfortunately, Intel has not provided much guidance in this area but has
indicated that software mitigation can and should be implemented by
libraries like OpenSSL. We're also not currently aware of any open CVEs
or embargos active for this particular side-channel attack.

Any help or guidance would be appreciated.

Can the openssl community comment on this?

Thanks!

--
/*
  * Michael R. Hines
  * Staff Engineer, DigitalOcean.
  */

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: request for TLBleed information / non-constant-time vulnerabilities

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Michael R. Hines via openssl-users
> Sent: Thursday, July 26, 2018 14:49
>
> 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?)

> Unfortunately, Intel has not provided much guidance in this area but has
> indicated that software mitigation can and should be implemented by
> libraries like OpenSSL.

Intel is spreading FUD, because they know perfectly well that microarchitecture side channel vulnerabilities are a big PR problem. So they're doing whatever they can to minimize the issue.

AMD similarly are pretending that just because no one's demonstrated a TLB side channel on their processors, that they don't have to worry about the possibilities.

> We're also not currently aware of any open CVEs
> or embargos active for this particular side-channel attack.

Well, no, because the manufacturers are claiming there is no problem, or if there is that it's someone else's.

More importantly, as the TLBleed authors, and the authors of the original Spectre paper, and many other researchers have pointed out, microarchitecture side channels are a large class of vulnerabilities. Spot defenses against particular variants rarely help protect against other variants. Microarchitecture side channel attacks will be with us for a long time.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: request for TLBleed information / non-constant-time vulnerabilities

OpenSSL - User mailing list

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
Reply | Threaded
Open this post in threaded view
|

Re: request for TLBleed information / non-constant-time vulnerabilities

Michael Wojcik
> From: Michael R. Hines [mailto:[hidden email]]
> Sent: Friday, July 27, 2018 07:48
>
>
> On 07/27/2018 08:35 AM, Michael Wojcik wrote:
> >
> > (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?)
>
> 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.

Oh, yes, of course you're correct. Sorry - that's what I get for responding early in the morning.

> If the
> cryptographic implementation is constant-time, then the bits are not
> discoverable and the attack is then unavailable.

Hmm. I suppose this is true, but it's not the usual sense of "constant time" when referring to cryptographic implementations - that is, it's not constant-time explicit operations (arithmetic, etc) but constant-time memory access, which requires the implementation to predict which pages it will touch, and to know something about the TLB algorithm used by the particular CPU it's running on.

I think that goes back to the TLBleed authors' mention of partitioning the target process virtual address space. For a library, that would be difficult, since it receives the key at an arbitrary address from the application.

> 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?

Certainly I'd need to do a lot more research before I'd feel comfortable speculating about possible mitigations within OpenSSL. I'll be interested to see if anyone else does.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: request for TLBleed information / non-constant-time vulnerabilities

OpenSSL - User mailing list

On 07/27/2018 09:12 AM, Michael Wojcik wrote:

>
>> 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?
> Certainly I'd need to do a lot more research before I'd feel comfortable speculating about possible mitigations within OpenSSL. I'll be interested to see if anyone else does.
>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus

Any and all guidance would be appreciated!

Again, thank you so much for the response. We're having a very difficult
time finding a response (of any kind)
from the crypto community or from the linux distributions as well.

- Michael
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: request for TLBleed information / non-constant-time vulnerabilities

Jakob Bohm-7
On 27/07/2018 16:20, Michael R. Hines via openssl-users wrote:

>
> On 07/27/2018 09:12 AM, Michael Wojcik wrote:
>>
>>> 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?
>> Certainly I'd need to do a lot more research before I'd feel
>> comfortable speculating about possible mitigations within OpenSSL.
>> I'll be interested to see if anyone else does.
>>
>> --
>> Michael Wojcik
>> Distinguished Engineer, Micro Focus
>
> Any and all guidance would be appreciated!
>
> Again, thank you so much for the response. We're having a very
> difficult time finding a response (of any kind)
> from the crypto community or from the linux distributions as well.
It looks from your descriptions (I haven't read the paper, and may
be wrong for other reasons too) like the most effective mitigation
(not always available) is to use code that doesn't do data-dependent
(incl. key-dependent) memory addressing.

However converting normal algorithms to a form that always accesses
the same memory bytes in the same order is a non-trivial job, and is
further complicated by the very real risk that any code optimizer
between you source code and the actual memory access hardware may
undo your carefully crafted mitigations.  (Such optimizers could
be in your compiler, in a JIT-based bytecode interpreter or even
in the kind of modern CPU that this attack targets).

And once you have done all that work to protect the cryptographic
library, the CPU vulnerability still allows the attacker to observer
the non-cryptographic application code that actually creates or uses
the plain text (after all, you don't need the plaintext if you are
not going to use it, or at least create it).

For example, the attacker may measure the memory access patterns of
the spell checker used when inputting the plain text, or the line
break and character width calculations in code that outputs the
plain text to an otherwise secure display.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: request for TLBleed information / non-constant-time vulnerabilities

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Jakob Bohm
> Sent: Friday, July 27, 2018 11:52
>
> And once you have done all that work to protect the cryptographic
> library, the CPU vulnerability still allows the attacker to observer
> the non-cryptographic application code that actually creates or uses
> the plain text (after all, you don't need the plaintext if you are
> not going to use it, or at least create it).

An interesting point. The limited bandwidth of most side-channel attacks means that these sorts of secondary secrets aren't usually targeted, but in many cases even small portions of plaintext might be useful. For example, extracting the Request-URIs from HTTP requests, or the RCPT TO lines from SMTP ones, can be useful for traffic and metadata analysis.

We're in an interesting period. Back in the '90s, practitioners like Bruce Schneier were saying that cryptography wasn't the problem - that it had developed to the point where it was too difficult to attack, and there were myriad weaknesses in how cryptography was used, and in the applications that relied on it, and in infrastructure aspects such as PKI, and in the users themselves, so those were the practical targets.

Then we had a couple of decades of ever-more and increasingly effective attacks on cryptosystems, including on the primitives themselves, and attacking the crypto became economically feasible again.

Meanwhile we've had a gradual accumulation of attacks against the physical mechanisms implementing the crypto. These started long ago, of course (Kocher's timing attacks, and TEMPEST before that, and indeed well before the advent of computational cryptography), but they've been picking up speed.

And the issues peripheral to cryptography - applications, infrastructure, users - haven't gone away.

More and better cryptography; more and better attacks against it.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: request for TLBleed information / non-constant-time vulnerabilities

OpenSSL - User mailing list

On 07/27/2018 01:44 PM, Michael Wojcik wrote:

>> From: openssl-users [mailto:[hidden email]] On Behalf
>> Of Jakob Bohm
>> Sent: Friday, July 27, 2018 11:52
>>
>> And once you have done all that work to protect the cryptographic
>> library, the CPU vulnerability still allows the attacker to observer
>> the non-cryptographic application code that actually creates or uses
>> the plain text (after all, you don't need the plaintext if you are
>> not going to use it, or at least create it).
> An interesting point. The limited bandwidth of most side-channel attacks means that these sorts of secondary secrets aren't usually targeted, but in many cases even small portions of plaintext might be useful. For example, extracting the Request-URIs from HTTP requests, or the RCPT TO lines from SMTP ones, can be useful for traffic and metadata analysis.
>
> We're in an interesting period. Back in the '90s, practitioners like Bruce Schneier were saying that cryptography wasn't the problem - that it had developed to the point where it was too difficult to attack, and there were myriad weaknesses in how cryptography was used, and in the applications that relied on it, and in infrastructure aspects such as PKI, and in the users themselves, so those were the practical targets.
>
> Then we had a couple of decades of ever-more and increasingly effective attacks on cryptosystems, including on the primitives themselves, and attacking the crypto became economically feasible again.
>
> Meanwhile we've had a gradual accumulation of attacks against the physical mechanisms implementing the crypto. These started long ago, of course (Kocher's timing attacks, and TEMPEST before that, and indeed well before the advent of computational cryptography), but they've been picking up speed.
>
> And the issues peripheral to cryptography - applications, infrastructure, users - haven't gone away.
>
> More and better cryptography; more and better attacks against it.

Forgive the stupid question, but what's the takeaway for a cloud
provider? Do we gather from these points that the entire set of timing
attacks will never really be known?

What does this confirm (or not confirm) about openssl's vulnerability
(or knowable status) to TLBleed?

- Michael
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: request for TLBleed information / non-constant-time vulnerabilities

Michael Wojcik
> From: Michael R. Hines [mailto:[hidden email]]
> Sent: Friday, July 27, 2018 19:06
>
> Forgive the stupid question, but what's the takeaway for a cloud
> provider?

Well, in general, it's probably the commonplace that security is a process, not a product. There will always be new attacks of some sort.

> Do we gather from these points that the entire set of timing
> attacks will never really be known?

That's probably a safe assumption, particularly if "timing attacks" is defined broadly. (There was a famous timing attack against the TENEX logon mechanism back in the 1970s; does that count?)

Even for computational timing attacks (like Kocher's) and microarchitectural timing attacks (like TLBleed), it would be impossible to prove you had the complete set unless the entire system was formally verified and the implementation could somehow be demonstrated to conform to the forrmal specification under all conditions.

In theory you can increase the noise on the channel to the point where it's no longer economical. Research on that goes back to at least the early 1990s. The problems, of course, are making sure you comprehensively inject noise into all the known channels, and finding users willing to pay the cost - increased noise means reduced efficiency. We see this trade-off in all sorts of side-channel attacks; in the cloud, for example, you have the various results showing security issues with memory deduplication.

For cloud computing, we've had at least a decade of research into this issue (see e.g. Ristenpart et al, "Hey, you, get off my cloud", published nine years ago so work presumably started no later than 2008). And it's still a problem, which means it's complicated and likely to be durable.

> What does this confirm (or not confirm) about openssl's vulnerability
> (or knowable status) to TLBleed?

Specifically? Not much. It goes more to the general principle that systems leak information as they do work. Ultimately it comes down to thermodynamics, and you never bet against thermodynamics.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: request for TLBleed information / non-constant-time vulnerabilities

OpenSSL - User mailing list
By the way, these responses have been very thoughtful. I just wanted to
say thanks!

/*
  * Michael R. Hines
  * Staff Engineer, DigitalOcean.
  */

On 07/28/2018 08:44 AM, Michael Wojcik wrote:

>> From: Michael R. Hines [mailto:[hidden email]]
>> Sent: Friday, July 27, 2018 19:06
>>
>> Forgive the stupid question, but what's the takeaway for a cloud
>> provider?
> Well, in general, it's probably the commonplace that security is a process, not a product. There will always be new attacks of some sort.
>
>> Do we gather from these points that the entire set of timing
>> attacks will never really be known?
> That's probably a safe assumption, particularly if "timing attacks" is defined broadly. (There was a famous timing attack against the TENEX logon mechanism back in the 1970s; does that count?)
>
> Even for computational timing attacks (like Kocher's) and microarchitectural timing attacks (like TLBleed), it would be impossible to prove you had the complete set unless the entire system was formally verified and the implementation could somehow be demonstrated to conform to the forrmal specification under all conditions.
>
> In theory you can increase the noise on the channel to the point where it's no longer economical. Research on that goes back to at least the early 1990s. The problems, of course, are making sure you comprehensively inject noise into all the known channels, and finding users willing to pay the cost - increased noise means reduced efficiency. We see this trade-off in all sorts of side-channel attacks; in the cloud, for example, you have the various results showing security issues with memory deduplication.
>
> For cloud computing, we've had at least a decade of research into this issue (see e.g. Ristenpart et al, "Hey, you, get off my cloud", published nine years ago so work presumably started no later than 2008). And it's still a problem, which means it's complicated and likely to be durable.
>
>> What does this confirm (or not confirm) about openssl's vulnerability
>> (or knowable status) to TLBleed?
> Specifically? Not much. It goes more to the general principle that systems leak information as they do work. Ultimately it comes down to thermodynamics, and you never bet against thermodynamics.
>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
>

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users