5 ms·

You do realise that JSSE has lots of timing attacks etc. and that's pretty much unfixable in managed code? It's also had numerous bugs in it's SSL/TLS implement

by richm44 12y ago

You do realise that JSSE has lots of timing attacks etc. and that's pretty much unfixable in managed code? It's also had numerous bugs in it's SSL/TLS implementation (mainly because no one uses it) such as mishandling zero length extensions (used for flagging support for a feature), failing to handle DH params that aren't a multiple of 64 bits (no sane reason) etc.

mike_hearn 12y ago
Yes, I know there have been timing attacks, and the ones I know about were fixed. So I'm not sure they're pretty much unfixable. Regardless, I am more afraid of buffer overflows and general memory management errors than I am of timing attacks. Heartbleed was orders of magnitude easier to exploit than (say) the Bleichenbacher attacks that JSSE has been vulnerable to.
- richm44 12y ago
  I'm saying they're unfixable because there's no way to tell the JIT to create constant-time code. Certainly Christopher Meyer has said that he's reported some that remain private since they've not been fixed. Heartbleed was certainly easier to exploit, than a timing attack - no disagreement there. But the Java SSL stack is pretty flakey and largely seems to be unused. It has lots of interoperability problems with other implementations and generally seems immature. It's not something I'd trust in production myself.
  - Someone1234 12y ago
    > I'm saying they're unfixable because there's no way to tell the JIT to create constant-time code. What does that even mean? If you write your fail and success states to follow the same exact code paths (i.e. no branches, breaks, returns, or similar for failed) then you've created a "constant time" function. The inputted parameters are dynamic so the JIT-compiler cannot optimise code away, and even if it could it would do so equally for both the failed or success states. > Certainly Christopher Meyer has said that he's reported some that remain private since they've not been fixed. I tried Googling that but nothing. Can you link whatever it is you're talking about?
    - richm44 12y ago
      Certainly. I was referring to this blog post, http://armoredbarista.blogspot.co.uk/2014/04/easter-hack-even-more-critical-bugs-in.html http://armoredbarista.blogspot.co.uk/2014/04/easter-hack-eve... however rereading it I see he was saying it was the ones in the hardware accelerators that haven't yet been fixed.
    - richm44 12y ago
      Sorry, I realised I'd failed to address your other point: "What does that even mean? If you write your fail and success states to follow the same exact code paths (i.e. no branches, breaks, returns, or similar for failed) then you've created a "constant time" function." Well, if you've got a JIT that is analysing which code actually executes, and no control over the optimisations then how do you achieve this? If the hotpath is normally the success condition for example then the JIT will optimise that more. The rare and more dangerous condition will be optimised less. If this happens of course will depend on the engine, but you can't control that without working at a much lower level than managed code offers.
      - Someone1234 12y ago
        > Well, if you've got a JIT that is analysing which code actually executes, and no control over the optimisations then how do you achieve this? The same is true with native code optimising. > If the hotpath is normally the success condition for example then the JIT will optimise that more. The paths should be identical for both failure and success states. That's fundamentally how you "fix" timing attacks. > If this happens of course will depend on the engine, but you can't control that without working at a much lower level than managed code offers. You write code that has no hot paths regardless of if correct/wrong. That's how timing attacks are mitigated in all languages.
        richm44 12y ago
        > The same is true with native code optimising. This is rubbish. If I use custom assembler then that's what gets run. Even if I use C code then I know what the result will be since I can actually check. > The paths should be identical for both failure and success states. That's fundamentally how you "fix" timing attacks. That's certainly the ideal. But it's impossible - one result will succeed the other won't. The aim is to make sure both take the same time which is an achievable goal, however to do this you need to know what will execute. You might have that guarantee in practice on a particular JVM for example, but the whole point of using something like a JIT is that it will be smart about optimising stuff based on what actually happens. That's normally great, but this is a situation where all that needed is predictability not performance.
  - mike_hearn 12y ago
    Right - it is looking more and more like truly constant time code can only be obtained by using hand written assembly or hardware. In that eventuality, I guess the core crypto code in the JVM will have to be changed to use hand written assembly as well, however, SSL is huge and most of it doesn't need to be constant time (certificate parsing, managing network buffers, message parsing etc). That is often where the bugs creep in. Going with JSSE does have the downside that it's less widely used. Browser makers don't patch it with the latest gizmos like they do with OpenSSL. However, it's at least got a full time development team (unlike OpenSSL until very recently), and ultimately if there are odd conformance bugs lurking the only way they'll be shaken out is by people using it for real. Passing the Qualys test is a good start, but for now my little website is ideal because it is unlikely to ever be popular enough to have serious scaling issues and I can tolerate some incompatibility with odd clients.
    - richm44 12y ago
      "Right - it is looking more and more like truly constant time code can only be obtained by using hand written assembly or hardware. In that eventuality, I guess the core crypto code in the JVM will have to be changed to use hand written assembly as well, however, SSL is huge and most of it doesn't need to be constant time (certificate parsing, managing network buffers, message parsing etc). That is often where the bugs creep in." I completely agree with you there. X.509 is a nightmare and it's not an area where constant time matters at all. Being resistant to buffer overruns and general logic errors is much more important there.
      - dvanduzer 12y ago
        X.509 is a nightmare because it is complex, and the political infrastructure is vulnerable. There is no reason ciphers like djb's that use data-independent code paths couldn't be integrated into X.509 if the will was there. Totally separate issues.
    - ars 12y ago
      > can only be obtained by using hand written assembly or hardware Even that is harder than it looks. For example, a common way of doing a constant time string compare is: $result |= (ord($safe[$i % $safeLen]) ^ ord($user[$i])); i.e. get the character to compare mod the length, so you wrap around if the length of the two strings is not the same. Unfortunately the mod operator does not take a constant time on a CPU! If the result is evenly divisible it's faster. So even in assembly you might not be able to protect from a timing attack. Even if you check your current CPU a new one might be different. (In this case a better way to do the compare is if the strings are not the same length, compare the attackers string against itself, and then return false.)
  - pjmlp 12y ago
    > I'm saying they're unfixable because there's no way to tell the JIT to create constant-time code. Your fallacy is that there are several JVMs to choose from, each with its own set of JIT and AOT compilers. Don't judge Java by OpenJDK, it is only the reference implementation.
- tptacek 12y ago
  It is not a good idea to act on the premise that things like the BB e=3 or BB "million message attack" are hard to exploit. They aren't. The e=3 vulnerability (or its more modern "BERserk" variant) are arguably much easier to exploit than Heartbleed. They allow you to --- offline, in advance --- make your own valid CA certificates.
Someone1234 12y ago
> You do realise that JSSE has lots of timing attacks etc. and that's pretty much unfixable in managed code? That makes no sense at all. Timing attacks aren't more or less exploitable in managed code than unmanaged code. Timing attacks are often the result of optimisations within the crypto library which inadvertently give away information, for example a loop which breaks on X != Y, instead of setting a failed = false bool and continuing to iterate through the rest of the array. Please explain how managed code makes timing attacks more likely.
- MagicWishMonkey 12y ago
  If anything running code in a managed environment would be less vulnerable to timing attacks, given the non-deterministic nature of the garbage collector.
  - Someone1234 12y ago
    I'm not sure I agree with that either. I'd argue they're both as bad as one another. Since GC is non-deterministic it means you just need more cycles for an accurate result (and plus you're already having to ignore other sources of latency, like network, disk IO, OS lock contention, etc). Timing attacks are generally a coding problems, both a JIT-ed managed codebase and a native block of code can contain them.
  - bmm6o 12y ago
    If there's timing information leaked by the implementation then non-deterministic interference by things like GC pauses (CPU load, network traffic, etc) are noise that raises the work effort of the attack but does not in general make it impossible. This is why "introduce a random sleep" is a terrible defense to a timing attack. Statistics doesn't care about the cause of the variability, if there are samples coming from different populations it can detect that.
    - jamesaguilar 12y ago
      > terrible defense In what sense? In the sense of not mathematically fixing the problem, or in the sense of leaving it feasible to exploit in reality?

by richm44 12y ago

mike_hearn 12y ago

Yes, I know there have been timing attacks, and the ones I know about were fixed. So I'm not sure they're pretty much unfixable. Regardless, I am more afraid of buffer overflows and general memory management errors than I am of timing attacks. Heartbleed was orders of magnitude easier to exploit than (say) the Bleichenbacher attacks that JSSE has been vulnerable to.

richm44 12y ago
I'm saying they're unfixable because there's no way to tell the JIT to create constant-time code. Certainly Christopher Meyer has said that he's reported some that remain private since they've not been fixed. Heartbleed was certainly easier to exploit, than a timing attack - no disagreement there. But the Java SSL stack is pretty flakey and largely seems to be unused. It has lots of interoperability problems with other implementations and generally seems immature. It's not something I'd trust in production myself.
- Someone1234 12y ago
  > I'm saying they're unfixable because there's no way to tell the JIT to create constant-time code. What does that even mean? If you write your fail and success states to follow the same exact code paths (i.e. no branches, breaks, returns, or similar for failed) then you've created a "constant time" function. The inputted parameters are dynamic so the JIT-compiler cannot optimise code away, and even if it could it would do so equally for both the failed or success states. > Certainly Christopher Meyer has said that he's reported some that remain private since they've not been fixed. I tried Googling that but nothing. Can you link whatever it is you're talking about?
  - richm44 12y ago
    Certainly. I was referring to this blog post, http://armoredbarista.blogspot.co.uk/2014/04/easter-hack-even-more-critical-bugs-in.html http://armoredbarista.blogspot.co.uk/2014/04/easter-hack-eve... however rereading it I see he was saying it was the ones in the hardware accelerators that haven't yet been fixed.
  - richm44 12y ago
    Sorry, I realised I'd failed to address your other point: "What does that even mean? If you write your fail and success states to follow the same exact code paths (i.e. no branches, breaks, returns, or similar for failed) then you've created a "constant time" function." Well, if you've got a JIT that is analysing which code actually executes, and no control over the optimisations then how do you achieve this? If the hotpath is normally the success condition for example then the JIT will optimise that more. The rare and more dangerous condition will be optimised less. If this happens of course will depend on the engine, but you can't control that without working at a much lower level than managed code offers.
    - Someone1234 12y ago
      > Well, if you've got a JIT that is analysing which code actually executes, and no control over the optimisations then how do you achieve this? The same is true with native code optimising. > If the hotpath is normally the success condition for example then the JIT will optimise that more. The paths should be identical for both failure and success states. That's fundamentally how you "fix" timing attacks. > If this happens of course will depend on the engine, but you can't control that without working at a much lower level than managed code offers. You write code that has no hot paths regardless of if correct/wrong. That's how timing attacks are mitigated in all languages.
      - richm44 12y ago
        > The same is true with native code optimising. This is rubbish. If I use custom assembler then that's what gets run. Even if I use C code then I know what the result will be since I can actually check. > The paths should be identical for both failure and success states. That's fundamentally how you "fix" timing attacks. That's certainly the ideal. But it's impossible - one result will succeed the other won't. The aim is to make sure both take the same time which is an achievable goal, however to do this you need to know what will execute. You might have that guarantee in practice on a particular JVM for example, but the whole point of using something like a JIT is that it will be smart about optimising stuff based on what actually happens. That's normally great, but this is a situation where all that needed is predictability not performance.
- mike_hearn 12y ago
  Right - it is looking more and more like truly constant time code can only be obtained by using hand written assembly or hardware. In that eventuality, I guess the core crypto code in the JVM will have to be changed to use hand written assembly as well, however, SSL is huge and most of it doesn't need to be constant time (certificate parsing, managing network buffers, message parsing etc). That is often where the bugs creep in. Going with JSSE does have the downside that it's less widely used. Browser makers don't patch it with the latest gizmos like they do with OpenSSL. However, it's at least got a full time development team (unlike OpenSSL until very recently), and ultimately if there are odd conformance bugs lurking the only way they'll be shaken out is by people using it for real. Passing the Qualys test is a good start, but for now my little website is ideal because it is unlikely to ever be popular enough to have serious scaling issues and I can tolerate some incompatibility with odd clients.
  - richm44 12y ago
    "Right - it is looking more and more like truly constant time code can only be obtained by using hand written assembly or hardware. In that eventuality, I guess the core crypto code in the JVM will have to be changed to use hand written assembly as well, however, SSL is huge and most of it doesn't need to be constant time (certificate parsing, managing network buffers, message parsing etc). That is often where the bugs creep in." I completely agree with you there. X.509 is a nightmare and it's not an area where constant time matters at all. Being resistant to buffer overruns and general logic errors is much more important there.
    - dvanduzer 12y ago
      X.509 is a nightmare because it is complex, and the political infrastructure is vulnerable. There is no reason ciphers like djb's that use data-independent code paths couldn't be integrated into X.509 if the will was there. Totally separate issues.
  - ars 12y ago
    > can only be obtained by using hand written assembly or hardware Even that is harder than it looks. For example, a common way of doing a constant time string compare is: $result |= (ord($safe[$i % $safeLen]) ^ ord($user[$i])); i.e. get the character to compare mod the length, so you wrap around if the length of the two strings is not the same. Unfortunately the mod operator does not take a constant time on a CPU! If the result is evenly divisible it's faster. So even in assembly you might not be able to protect from a timing attack. Even if you check your current CPU a new one might be different. (In this case a better way to do the compare is if the strings are not the same length, compare the attackers string against itself, and then return false.)
- pjmlp 12y ago
  > I'm saying they're unfixable because there's no way to tell the JIT to create constant-time code. Your fallacy is that there are several JVMs to choose from, each with its own set of JIT and AOT compilers. Don't judge Java by OpenJDK, it is only the reference implementation.
tptacek 12y ago
It is not a good idea to act on the premise that things like the BB e=3 or BB "million message attack" are hard to exploit. They aren't. The e=3 vulnerability (or its more modern "BERserk" variant) are arguably much easier to exploit than Heartbleed. They allow you to --- offline, in advance --- make your own valid CA certificates.

Someone1234 12y ago

> You do realise that JSSE has lots of timing attacks etc. and that's pretty much unfixable in managed code? That makes no sense at all. Timing attacks aren't more or less exploitable in managed code than unmanaged code. Timing attacks are often the result of optimisations within the crypto library which inadvertently give away information, for example a loop which breaks on X != Y, instead of setting a failed = false bool and continuing to iterate through the rest of the array. Please explain how managed code makes timing attacks more likely.

MagicWishMonkey 12y ago
If anything running code in a managed environment would be less vulnerable to timing attacks, given the non-deterministic nature of the garbage collector.
- Someone1234 12y ago
  I'm not sure I agree with that either. I'd argue they're both as bad as one another. Since GC is non-deterministic it means you just need more cycles for an accurate result (and plus you're already having to ignore other sources of latency, like network, disk IO, OS lock contention, etc). Timing attacks are generally a coding problems, both a JIT-ed managed codebase and a native block of code can contain them.
- bmm6o 12y ago
  If there's timing information leaked by the implementation then non-deterministic interference by things like GC pauses (CPU load, network traffic, etc) are noise that raises the work effort of the attack but does not in general make it impossible. This is why "introduce a random sleep" is a terrible defense to a timing attack. Statistics doesn't care about the cause of the variability, if there are samples coming from different populations it can detect that.
  - jamesaguilar 12y ago
    > terrible defense In what sense? In the sense of not mathematically fixing the problem, or in the sense of leaving it feasible to exploit in reality?