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.
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.
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.
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?
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?
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.
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.
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.
[+] [-] eps|12 years ago|reply
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|12 years ago|reply
[+] [-] paulannesley|12 years ago|reply
> Not used anywhere though, just a corpse lying around in the code. — Jann Horn
[+] [-] bgwhn|12 years ago|reply
[+] [-] chomp|12 years ago|reply
EDIT: I see it exposed in 0.9.8y. Anyone know of anything that builds against this specifically and uses it?
[+] [-] bgwhn|12 years ago|reply
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/1aa54bebaf274bc08e72f9ad38...
[+] [-] duskwuff|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] mbell|12 years ago|reply
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).
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] ksoderstrom|12 years ago|reply
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?
[+] [-] Nexxxeh|12 years ago|reply
[+] [-] bgwhn|12 years ago|reply
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.
[+] [-] deadfa11|12 years ago|reply
[+] [-] Moral_|12 years ago|reply
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.
[+] [-] Rygu|12 years ago|reply