5 ms·

OpenSSL vulnerable to timing attack?

53 points by Moral_ 13y ago

chomp 13y ago
I don't see this function called anywhere in the OpenSSL source, or, for instance, the Apache source code. Could you clarify on this post? EDIT: I see it exposed in 0.9.8y. Anyone know of anything that builds against this specifically and uses it?
- deleted 13y ago
  [deleted]
- pipeep 13y ago
  Seeing as it's static, it's not part of the public API. Apparently it was used in Ruby at one point: https://groups.google.com/forum/#!topic/mailing.openssl.dev/7kcdEa5lpLI https://groups.google.com/forum/#!topic/mailing.openssl.dev/... I think it's probably a piece of dead code at this point, but there might be some legacy stuff using it (with an old version of OpenSSL), which could lead to a vulnerability. Regardless, the function should probably be rewritten or removed. EDIT: It looks like the latest version of Ruby (MRI) actually copied this function from OpenSSL so they could keep using it: https://github.com/ruby/ruby/blob/1aa54bebaf274bc08e72f9ad3854c7ad592c344a/ext/openssl/ossl_ssl_session.c#L76 https://github.com/ruby/ruby/blob/1aa54bebaf274bc08e72f9ad38...
  - chomp 13y ago
    Yeah, I'm thinking it's dead code. It's not exposed in modern OpenSSLs, and I can't find any services we use (Pure-FTP, httpd, etc) that use this function. OpenSSL devs should probably remove this code.
    - pipeep 13y ago
      It looks like there's some github projects using it: https://github.com/search?q=SSL_SESSION_cmp&ref=cmdform&type=Code https://github.com/search?q=SSL_SESSION_cmp&ref=cmdform&type...
  - pipeep 13y ago
    I made a patch to ruby swapping the memcmp for CRYPTO_memcmp, which should be constant-time. I'm checking to see that I didn't break the build, after which I'll make a pull request to https://github.com/ruby/ruby https://github.com/ruby/ruby. Then it'll be up to the ruby developers, who probably have better insight into this than me, to accept or decline it. EDIT: For anyone interested: https://github.com/ruby/ruby/pull/591 https://github.com/ruby/ruby/pull/591
  - petermalone 13y ago
    The current version of Android also uses it.
    - pipeep 13y ago
      Link?
      - petermalone 13y ago
        https://android.googlesource.com/platform/external/openssl/+/android-4.4.2_r2/ssl/ssl_lib.c https://android.googlesource.com/platform/external/openssl/+...
        pipeep 13y ago
        It's marked as static and isn't used anywhere there, so it's not an issue: they have an up-to-date version of upstream OpenSSL.
        petermalone 13y ago
        Ah - good to know. Cheers!
- duskwuff 13y ago
  Even if it were used, how large is a SSL_SESSION, and does a client have any control over its contents? Not every memcmp() is necessarily vulnerable.
  - jas203 13y ago
    Session IDs themselves are public; namely they may be exchanged in the plain text as part of an initial TLS handshake. They are used for session resumption to look-up confidential (e.g. keying) information that should be stored in a protected manner by the TLS peers.
    - duskwuff 13y ago
      Given that the session ID is exchanged in plaintext, I'm definitely not seeing the security risk here. At best, you could potentially use a timing attack to recover the contents of a session ID, but you can already get that by sniffing the network. And in any case, even if you did get that, I don't think there's anything interesting you could do with it.
      - jas203 13y ago
        That is my point.
- mbell 13y ago
  > EDIT: I see it exposed in 0.9.8y. Anyone know of anything that builds against this specifically and uses it? I don't know of anything that builds against that version specifically but it is the version that is included in OS X as of 10.9 (and possibly 10.8).
deleted 13y ago
[deleted]
Nexxxeh 13y ago
Heartbleed I just about understand, as despite this not being my field, smart people successfully summarized it in an easily digestible way so that I could even explain it to my mum. Can someone ELI5 this too please?
- deadfa11 13y ago
  Basically, measure the time difference in the memory comparison. Typically, comparisons will short-circuit. That is, stop as soon as a difference is detected. But this is a problem for security situations like key comparisons. If 10 out of 20 bytes match, it will take a little bit longer to compare then if 5 out of 20 bytes match. With enough iterations, the key can be recovered due to these differences in time. The correct solution is to use a constant time comparison that always runs through the entire sequence of bytes.
- Rygu 13y ago
  See that the memcmp() comparison takes longer as you guess the next byte correctly. Repeat until all bytes known.
- Moral_ 13y ago
  memcmp does a binary level comparison of data. On many versions, memcmp will return exactly when it sees a difference between the two buffers. Because it returns immediately one can figure out what byte it failed at due to timing and construct the correct input. Some others have pointed out that it's a static function, which I stupidly overlooked. Others have pointed out it's not really used anymore so the title doesn't accurately reflect the issue. -- I will probably delete this thread.
  - pipeep 13y ago
    It wasn't static for older versions of OpenSSL, so this still might be an issue if someone was using that function with the assumption of it being constant-time.
- pipeep 13y ago
  memcmp compares two blocks of memory byte-by-byte. If the first two bytes don't match, the function can return early, otherwise it has to check the next byte. By measuring the execution times for all 256 possible bytes, one should be able to guess the first byte. Repeat this for the length of the memory being compared, and you should be able to essentially read the entire block of memory you're being compared against. These attacks are usually done over a fast connection (maybe buy a machine in the same datacenter as your target), and through lots of measurements averaged together and measured for statistical significance. We don't know where this function is used, so this might actually be a non-issue. We need someone more familiar with OpenSSL to comment.
eps 13y ago
This could, in theory, allow discovering IDs of sessions that are either active or cached on the server end. IDs are passed in clear between SSL peers, so being able to recover them doesn't compromise the security of the protocol. That said, this can be used to estimate the size of the server's session list and to covertly measure and monitor the volume of its activity. This can come handy in some cases, but then splicing into server's Internet connection and passively listening to the traffic would yield the same information with much less fuss.
- tptacek 13y ago
  C memcmp() timing channels are extremely difficult in practice to exploit, even at relatively close proximity to targets, so I'm not sure how practical any of this is.
  - pipeep 13y ago
    It's probably not practical, but it doesn't hurt to fix or remove (it's not used internally in OpenSSL) the code anyways. I submitted a pull request to Ruby, where the code was copied to, and is used: https://github.com/ruby/ruby/pull/591 https://github.com/ruby/ruby/pull/591 .
paulannesley 13y ago
Follow-up email: http://seclists.org/fulldisclosure/2014/Apr/149 http://seclists.org/fulldisclosure/2014/Apr/149 > Not used anywhere though, just a corpse lying around in the code. — Jann Horn
- pipeep 13y ago
  Not in OpenSSL, but Ruby uses it: https://github.com/ruby/ruby/blob/1aa54bebaf274bc08e72f9ad3854c7ad592c344a/ext/openssl/ossl_ssl_session.c#L76 https://github.com/ruby/ruby/blob/1aa54bebaf274bc08e72f9ad38...
  - stusmall 13y ago
    Ruby uses a version of it they copied into their source tree. You can't really fault OpenSSL for another project copying one of their internal, static functions. I've never looked at Ruby's code base before. Did they just fork all of OpenSSL? EDIT: I see you made a patch for it. High five!
    - pipeep 13y ago
      The code in question is a Ruby FFI wrapper for OpenSSL (not a fork). Originally the function wasn't static, so when OpenSSL made it static, Ruby copied the function implementation to their source tree, as to avoid breaking their API.
ksoderstrom 13y ago
Is it actually feasible to do a timing attack using memcpy? I've been testing a bit locally, as in within the same process, without any luck. I have a hard to seeing how this would work, especially when you add network latency. Does anyone have any proof-of-concept code that actually exploits memcpy with a timing attack?

53 points by Moral_ 13y ago

chomp 13y ago

I don't see this function called anywhere in the OpenSSL source, or, for instance, the Apache source code. Could you clarify on this post? EDIT: I see it exposed in 0.9.8y. Anyone know of anything that builds against this specifically and uses it?

deleted 13y ago
[deleted]
pipeep 13y ago
Seeing as it's static, it's not part of the public API. Apparently it was used in Ruby at one point: https://groups.google.com/forum/#!topic/mailing.openssl.dev/7kcdEa5lpLI https://groups.google.com/forum/#!topic/mailing.openssl.dev/... I think it's probably a piece of dead code at this point, but there might be some legacy stuff using it (with an old version of OpenSSL), which could lead to a vulnerability. Regardless, the function should probably be rewritten or removed. EDIT: It looks like the latest version of Ruby (MRI) actually copied this function from OpenSSL so they could keep using it: https://github.com/ruby/ruby/blob/1aa54bebaf274bc08e72f9ad3854c7ad592c344a/ext/openssl/ossl_ssl_session.c#L76 https://github.com/ruby/ruby/blob/1aa54bebaf274bc08e72f9ad38...
- chomp 13y ago
  Yeah, I'm thinking it's dead code. It's not exposed in modern OpenSSLs, and I can't find any services we use (Pure-FTP, httpd, etc) that use this function. OpenSSL devs should probably remove this code.
  - pipeep 13y ago
    It looks like there's some github projects using it: https://github.com/search?q=SSL_SESSION_cmp&ref=cmdform&type=Code https://github.com/search?q=SSL_SESSION_cmp&ref=cmdform&type...
- pipeep 13y ago
  I made a patch to ruby swapping the memcmp for CRYPTO_memcmp, which should be constant-time. I'm checking to see that I didn't break the build, after which I'll make a pull request to https://github.com/ruby/ruby https://github.com/ruby/ruby. Then it'll be up to the ruby developers, who probably have better insight into this than me, to accept or decline it. EDIT: For anyone interested: https://github.com/ruby/ruby/pull/591 https://github.com/ruby/ruby/pull/591
- petermalone 13y ago
  The current version of Android also uses it.
  - pipeep 13y ago
    Link?
    - petermalone 13y ago
      https://android.googlesource.com/platform/external/openssl/+/android-4.4.2_r2/ssl/ssl_lib.c https://android.googlesource.com/platform/external/openssl/+...
      - pipeep 13y ago
        It's marked as static and isn't used anywhere there, so it's not an issue: they have an up-to-date version of upstream OpenSSL.
        petermalone 13y ago
        Ah - good to know. Cheers!
duskwuff 13y ago
Even if it were used, how large is a SSL_SESSION, and does a client have any control over its contents? Not every memcmp() is necessarily vulnerable.
- jas203 13y ago
  Session IDs themselves are public; namely they may be exchanged in the plain text as part of an initial TLS handshake. They are used for session resumption to look-up confidential (e.g. keying) information that should be stored in a protected manner by the TLS peers.
  - duskwuff 13y ago
    Given that the session ID is exchanged in plaintext, I'm definitely not seeing the security risk here. At best, you could potentially use a timing attack to recover the contents of a session ID, but you can already get that by sniffing the network. And in any case, even if you did get that, I don't think there's anything interesting you could do with it.
    - jas203 13y ago
      That is my point.
mbell 13y ago
> EDIT: I see it exposed in 0.9.8y. Anyone know of anything that builds against this specifically and uses it? I don't know of anything that builds against that version specifically but it is the version that is included in OS X as of 10.9 (and possibly 10.8).

deleted 13y ago

[deleted]

Nexxxeh 13y ago

Heartbleed I just about understand, as despite this not being my field, smart people successfully summarized it in an easily digestible way so that I could even explain it to my mum. Can someone ELI5 this too please?

deadfa11 13y ago
Basically, measure the time difference in the memory comparison. Typically, comparisons will short-circuit. That is, stop as soon as a difference is detected. But this is a problem for security situations like key comparisons. If 10 out of 20 bytes match, it will take a little bit longer to compare then if 5 out of 20 bytes match. With enough iterations, the key can be recovered due to these differences in time. The correct solution is to use a constant time comparison that always runs through the entire sequence of bytes.
Rygu 13y ago
See that the memcmp() comparison takes longer as you guess the next byte correctly. Repeat until all bytes known.
Moral_ 13y ago
memcmp does a binary level comparison of data. On many versions, memcmp will return exactly when it sees a difference between the two buffers. Because it returns immediately one can figure out what byte it failed at due to timing and construct the correct input. Some others have pointed out that it's a static function, which I stupidly overlooked. Others have pointed out it's not really used anymore so the title doesn't accurately reflect the issue. -- I will probably delete this thread.
- pipeep 13y ago
  It wasn't static for older versions of OpenSSL, so this still might be an issue if someone was using that function with the assumption of it being constant-time.
pipeep 13y ago
memcmp compares two blocks of memory byte-by-byte. If the first two bytes don't match, the function can return early, otherwise it has to check the next byte. By measuring the execution times for all 256 possible bytes, one should be able to guess the first byte. Repeat this for the length of the memory being compared, and you should be able to essentially read the entire block of memory you're being compared against. These attacks are usually done over a fast connection (maybe buy a machine in the same datacenter as your target), and through lots of measurements averaged together and measured for statistical significance. We don't know where this function is used, so this might actually be a non-issue. We need someone more familiar with OpenSSL to comment.

eps 13y ago

This could, in theory, allow discovering IDs of sessions that are either active or cached on the server end. IDs are passed in clear between SSL peers, so being able to recover them doesn't compromise the security of the protocol. That said, this can be used to estimate the size of the server's session list and to covertly measure and monitor the volume of its activity. This can come handy in some cases, but then splicing into server's Internet connection and passively listening to the traffic would yield the same information with much less fuss.

tptacek 13y ago
C memcmp() timing channels are extremely difficult in practice to exploit, even at relatively close proximity to targets, so I'm not sure how practical any of this is.
- pipeep 13y ago
  It's probably not practical, but it doesn't hurt to fix or remove (it's not used internally in OpenSSL) the code anyways. I submitted a pull request to Ruby, where the code was copied to, and is used: https://github.com/ruby/ruby/pull/591 https://github.com/ruby/ruby/pull/591 .

paulannesley 13y ago

Follow-up email: http://seclists.org/fulldisclosure/2014/Apr/149 http://seclists.org/fulldisclosure/2014/Apr/149 > Not used anywhere though, just a corpse lying around in the code. — Jann Horn

pipeep 13y ago
Not in OpenSSL, but Ruby uses it: https://github.com/ruby/ruby/blob/1aa54bebaf274bc08e72f9ad3854c7ad592c344a/ext/openssl/ossl_ssl_session.c#L76 https://github.com/ruby/ruby/blob/1aa54bebaf274bc08e72f9ad38...
- stusmall 13y ago
  Ruby uses a version of it they copied into their source tree. You can't really fault OpenSSL for another project copying one of their internal, static functions. I've never looked at Ruby's code base before. Did they just fork all of OpenSSL? EDIT: I see you made a patch for it. High five!
  - pipeep 13y ago
    The code in question is a Ruby FFI wrapper for OpenSSL (not a fork). Originally the function wasn't static, so when OpenSSL made it static, Ruby copied the function implementation to their source tree, as to avoid breaking their API.

ksoderstrom 13y ago

Is it actually feasible to do a timing attack using memcpy? I've been testing a bit locally, as in within the same process, without any luck. I have a hard to seeing how this would work, especially when you add network latency. Does anyone have any proof-of-concept code that actually exploits memcpy with a timing attack?