5 ms·

Are these actually novel vulnerabilities, or just unpatched CBC vulnerabilities? As far as I am aware CBC has been discouraged for a long time precisely because

Are these actually novel vulnerabilities, or just unpatched CBC vulnerabilities? As far as I am aware CBC has been discouraged for a long time precisely because of the padding oracle attacks.

olliej 8y ago
That was my exact thought - CBC mode is not secure against a vast array of attacks, and I’m not sure if I want to read an entire paper to determine if there’s anything new/novel in attacking a known weak cipher mode
- olliej 8y ago
  Ok, so I did the work of reading/skimming :D Essentially these are implementation specific bugs resulting in oracles, rather than being attacks on CBC itself - basically openssl and some embedded (?) TLS stacks produce different results (delayed hang up and/or different error codes) for padding vs. MAC failures in CBC mode. I assume that the joy of CBC mode just makes those oracles easier to directly exploit. The exploits are still harder to use than GCM with a reused nonce (reusing a nonce in GCM mode essentially breaks it. GCM is hard).
- tptacek 8y ago
  No, this isn't true. CBC mode is generally fine. The problem is improperly authenticated CBC. But improperly authenticated CTR is also insecure, and CTR is an essential building block of a whole bunch of modern AEAD schemes, including GCM. CBC mode is also susceptible to attacks based on predictable IVs. But again, CTR is susceptible to a sort of isomorphic class of bugs related to repeated nonces --- as, of course, is GCM, which you mention before; GCM not only inherits CTR's brittleness with respect to nonces but also fails in spectacular new ways with them. Arguably, if you're going to have to build your own cryptosystem from primitives (don't do this), you have the best chance of success with random-IV CBC mode and HMAC-SHA2 in an EtM configuration. You're less likely to blow that up than GCM. The research here is in detecting instances of the well-understood CBC padding oracle flaw. A new measurement technique that surfaced a whole bunch of new instances of heap overflows in server software would be an important contribution, in the same way this is.
  - weinzierl 8y ago
    > You're less likely to blow that up than GCM. Do you have a pointer where I can read about traps of GCM?
    - tptacek 8y ago
      I don't know the best summary, but the broad strokes are that nonce reuse both destroys confidentiality and allows recovery of authentication keys --- this is an extraordinarily common problem and one attackers can sometimes induce --- as does truncating the GCM MAC, and, if you don't have hardware support for GCM (ie, x64 CLMUL), the table-based version is timable.
      - deleted 8y ago
        [deleted]
lol768 8y ago
>As far as I am aware CBC has been discouraged for a long time precisely because of the padding oracle attacks My understanding of these padding oracle attacks was that they were the result of an implementation vulnerability that leaked information through error messages about the padding being the cause. Not that the problem was an inherent flaw in CBC itself. If the server simply used generic error messages when the padding was invalid, there would be no 'oracle' AIUI. Edit: https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf
- bcaa7f3a8bbc 8y ago
  > Not that there was an inherent flaw in CBC itself. But if history shows it's difficult to implement something without creating vulnerabilities, and there are alternatives which are less prone to mistakes, it should be retired and discouraged to be implemented. Also, CBC itself is not an actual problem, but CBC in TLS is authenticate-then-encrypt, which is how the vast majority of problems are created.
  - lol768 8y ago
    >But if history shows it's difficult to implement something without creating vulnerabilities, and there are alternatives which are less prone to mistakes, it should be retired and discouraged to be implemented. >Also, CBC itself is not an actual problem, but CBC in TLS is authenticate-then-encrypt, which is how the vast majority of problems are created. Oh definitely, GCM (or another AEAD cipher) is a much better choice - I wouldn't argue in favour of CBC in production TLS cipher suites. I just wanted to comment on the technical details of where padding oracle vulnerabilities actually arise.
    - blattimwind 8y ago
      > Oh definitely, GCM (or another AEAD cipher) is a much better choice GCM is only a better choice if you have hardware support for it. I'd recommend Chacha20-Poly1305 for anything that might have to cope without hardware support.
  - 8y ago
tptacek 8y ago
They're novel instances of a bug class, the same way a new use-after-free in Chrome is a novel bug. This is what makes crypto vuln research so great: the published work deals mostly in bug classes, which can be leveraged against systems ad infinitum.

Are these actually novel vulnerabilities, or just unpatched CBC vulnerabilities? As far as I am aware CBC has been discouraged for a long time precisely because of the padding oracle attacks.

olliej 8y ago

That was my exact thought - CBC mode is not secure against a vast array of attacks, and I’m not sure if I want to read an entire paper to determine if there’s anything new/novel in attacking a known weak cipher mode

olliej 8y ago
Ok, so I did the work of reading/skimming :D Essentially these are implementation specific bugs resulting in oracles, rather than being attacks on CBC itself - basically openssl and some embedded (?) TLS stacks produce different results (delayed hang up and/or different error codes) for padding vs. MAC failures in CBC mode. I assume that the joy of CBC mode just makes those oracles easier to directly exploit. The exploits are still harder to use than GCM with a reused nonce (reusing a nonce in GCM mode essentially breaks it. GCM is hard).
tptacek 8y ago
No, this isn't true. CBC mode is generally fine. The problem is improperly authenticated CBC. But improperly authenticated CTR is also insecure, and CTR is an essential building block of a whole bunch of modern AEAD schemes, including GCM. CBC mode is also susceptible to attacks based on predictable IVs. But again, CTR is susceptible to a sort of isomorphic class of bugs related to repeated nonces --- as, of course, is GCM, which you mention before; GCM not only inherits CTR's brittleness with respect to nonces but also fails in spectacular new ways with them. Arguably, if you're going to have to build your own cryptosystem from primitives (don't do this), you have the best chance of success with random-IV CBC mode and HMAC-SHA2 in an EtM configuration. You're less likely to blow that up than GCM. The research here is in detecting instances of the well-understood CBC padding oracle flaw. A new measurement technique that surfaced a whole bunch of new instances of heap overflows in server software would be an important contribution, in the same way this is.
- weinzierl 8y ago
  > You're less likely to blow that up than GCM. Do you have a pointer where I can read about traps of GCM?
  - tptacek 8y ago
    I don't know the best summary, but the broad strokes are that nonce reuse both destroys confidentiality and allows recovery of authentication keys --- this is an extraordinarily common problem and one attackers can sometimes induce --- as does truncating the GCM MAC, and, if you don't have hardware support for GCM (ie, x64 CLMUL), the table-based version is timable.
    - deleted 8y ago
      [deleted]

lol768 8y ago

>As far as I am aware CBC has been discouraged for a long time precisely because of the padding oracle attacks My understanding of these padding oracle attacks was that they were the result of an implementation vulnerability that leaked information through error messages about the padding being the cause. Not that the problem was an inherent flaw in CBC itself. If the server simply used generic error messages when the padding was invalid, there would be no 'oracle' AIUI. Edit: https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

bcaa7f3a8bbc 8y ago
> Not that there was an inherent flaw in CBC itself. But if history shows it's difficult to implement something without creating vulnerabilities, and there are alternatives which are less prone to mistakes, it should be retired and discouraged to be implemented. Also, CBC itself is not an actual problem, but CBC in TLS is authenticate-then-encrypt, which is how the vast majority of problems are created.
- lol768 8y ago
  >But if history shows it's difficult to implement something without creating vulnerabilities, and there are alternatives which are less prone to mistakes, it should be retired and discouraged to be implemented. >Also, CBC itself is not an actual problem, but CBC in TLS is authenticate-then-encrypt, which is how the vast majority of problems are created. Oh definitely, GCM (or another AEAD cipher) is a much better choice - I wouldn't argue in favour of CBC in production TLS cipher suites. I just wanted to comment on the technical details of where padding oracle vulnerabilities actually arise.
  - blattimwind 8y ago
    > Oh definitely, GCM (or another AEAD cipher) is a much better choice GCM is only a better choice if you have hardware support for it. I'd recommend Chacha20-Poly1305 for anything that might have to cope without hardware support.
- 8y ago

tptacek 8y ago

They're novel instances of a bug class, the same way a new use-after-free in Chrome is a novel bug. This is what makes crypto vuln research so great: the published work deals mostly in bug classes, which can be leveraged against systems ad infinitum.