3 ms·

As far as I can tell (I can't read O'Caml very well) the crypto library underpinning this makes the same mistake that all PKCS#1 signature verification function

by ctz 12y ago

As far as I can tell (I can't read O'Caml very well) the crypto library underpinning this makes the same mistake that all PKCS#1 signature verification functions have had at some point or another: they unpick the padding by hand[1], and then decode the ASN1 DigestInfo. The only sane way to do this is to generate the padding from scratch and check if the signature plaintext is the same (the added benefit is your ASN1 decoder is now not on a front-line security boundary). Is this exploitable in this bounty? No idea. At least, it's the right kind of vulnerability you need to forge a certificate. CVE-2014-1568 was this problem in NSS. [1]: https://github.com/mirleft/ocaml-nocrypto/blob/master/src/rsa.ml#L151 https://github.com/mirleft/ocaml-nocrypto/blob/master/src/rs...

hannesm 12y ago
This is about the DigestInfo -- which we generate and compare here: https://github.com/mirleft/ocaml-tls/blob/master/lib/handshake_common.ml#L186 https://github.com/mirleft/ocaml-tls/blob/master/lib/handsha... The unpad does RSA unpadding... or am I completely mistaken?
- ctz 12y ago
  I was reading the X509 certificate verification code, rather than the TLS code: https://github.com/mirleft/ocaml-x509/blob/master/lib/certificate.ml#L157 https://github.com/mirleft/ocaml-x509/blob/master/lib/certif...
  - pqwy 12y ago
    Why do you think this creates malleability? PKCS1.5 stripping takes away the leading 0x00 0x01 0xff ... 0x00 -- if this prefix is not present, it fails. The rest goes through the RSA tranform, and is parsed as PKCS1 DigestInfo, an ASN.1 structure. All ASN parsing checks for presence of trailing bytes, on top and in CONSTRUCTED nodes. The presence of suffix-checking prevents malleability in my mind. Am I missing something?
    - ctz 12y ago
      ASN parsing code, in general, does not check for presence of trailing bytes (see Bleichenbacher's original signature forgery attack, and CVEs passim). Should they? Yes. Do they? No, it is a frequent implementation error. In NSS, they did check for trailing bytes, but allowed one part of the ASN1 structure to have an arbitrary value (to work around flaws in other implementations). To be abundantly clear: I am not saying that any of the presented code has an exploitable flaw. I am saying that the way the code is written has frequently been found to be faulty in the past.
      - hannesm 12y ago
        "ASN parsing code, in general"... this sounds like you're a bit stuck in ad-hoc ASN.1 parsers written in C... We actually use combinators for doing that - this explains our ASN.1 library in more depth: http://openmirage.org/blog/introducing-asn1 http://openmirage.org/blog/introducing-asn1

by ctz 12y ago

hannesm 12y ago

This is about the DigestInfo -- which we generate and compare here: https://github.com/mirleft/ocaml-tls/blob/master/lib/handshake_common.ml#L186 https://github.com/mirleft/ocaml-tls/blob/master/lib/handsha... The unpad does RSA unpadding... or am I completely mistaken?

ctz 12y ago
I was reading the X509 certificate verification code, rather than the TLS code: https://github.com/mirleft/ocaml-x509/blob/master/lib/certificate.ml#L157 https://github.com/mirleft/ocaml-x509/blob/master/lib/certif...
- pqwy 12y ago
  Why do you think this creates malleability? PKCS1.5 stripping takes away the leading 0x00 0x01 0xff ... 0x00 -- if this prefix is not present, it fails. The rest goes through the RSA tranform, and is parsed as PKCS1 DigestInfo, an ASN.1 structure. All ASN parsing checks for presence of trailing bytes, on top and in CONSTRUCTED nodes. The presence of suffix-checking prevents malleability in my mind. Am I missing something?
  - ctz 12y ago
    ASN parsing code, in general, does not check for presence of trailing bytes (see Bleichenbacher's original signature forgery attack, and CVEs passim). Should they? Yes. Do they? No, it is a frequent implementation error. In NSS, they did check for trailing bytes, but allowed one part of the ASN1 structure to have an arbitrary value (to work around flaws in other implementations). To be abundantly clear: I am not saying that any of the presented code has an exploitable flaw. I am saying that the way the code is written has frequently been found to be faulty in the past.
    - hannesm 12y ago
      "ASN parsing code, in general"... this sounds like you're a bit stuck in ad-hoc ASN.1 parsers written in C... We actually use combinators for doing that - this explains our ASN.1 library in more depth: http://openmirage.org/blog/introducing-asn1 http://openmirage.org/blog/introducing-asn1