3 ms·

Isn't it notoriously difficult to write a sane, not exploitable asn.1 parser? The openssh didn't want to use x.509 certs for say because they considered asn.1 t

Isn't it notoriously difficult to write a sane, not exploitable asn.1 parser? The openssh didn't want to use x.509 certs for say because they considered asn.1 too risky and difficult iirc.

tialaramex 8y ago
It is notoriously difficult, but to be fair a big part of that notoriety arises in the era when you'd have written this in C, as indeed OpenSSH is written in C. You obviously should not write such software in a language as unsafe as C today. The Distinguished Encoding (DER) used for X.509 forces everything to be unambiguous, so in principle in a language where you can translate that lack of ambiguity into code and not inadvertently have it execute the raw data if you have an off-by-one error this seems no more dangerous than the present use of ASCII. It's just that C has fewer obvious sharp corners when it comes to parsing ASCII and programmers who work mostly in C knew where they were. On the other hand, X.509 is also a scary choice because it's a thicket of options. One of the biggest pieces of work done in the Web PKI has been telling Certificate Authorities not to issue stuff with random options filled out, because that's yet more code surface area to either cause interoperability issues or worse, security problems. For the former, an example is Let's Encrypt. You may notice today your Let's Encrypt intermediate is named X3. What happened to X1 and X2? Well they are created in pairs, so that's why there were more, but it doesn't explain why we're not still using X1. The answer there is that X1 contains a feature called a negative (prohibitive) Name Constraint. This is a way to say in X.509 that the issuer (in this case "DST Root CA X3" operated by Identrust) does not permit this intermediate CA to issue for specific names. Let's Encrypt had a constraint forbidding the US military TLD .mil But Windows XP doesn't understand this optional X.509 feature, if it sees any name constraint that it doesn't understand it concludes that all names are forbidden. So having this constraint meant Let's Encrypt was useless for Win XP clients. Identrust agreed to have Let's Encrypt simply obey this as a policy (and then they subsequently abandoned the policy) to enable XP compatibility. So, avoiding X.509 might have been a sensible choice in OpenSSH but that doesn't necessarily mean using ASN.1 DER would necessarily be a bad choice in new systems today. I don't see any reason to use BER or other encodings of ASN.1 in new systems.
- blattimwind 8y ago
  With ASN.1 there are also [the relatively new] OER, whose encoding rules seem significantly simpler than the previous ones (but may require transmitting one or the other bit more). W.r.t. parser security, I don't think that has been a success, historically, regardless of format. Few if any parsers for moderately complex formats have had zero vulnerabilities. If you think of a web server, or an XML library, or something similar, chances are pretty good it had at the very least one critical vulnerability related to parsing.
userbinator 8y ago
ASN.1 DER (the variety used for X.509) is IMHO quite easy to parse. It's a TLV (tag-length-value) format, so you know the lengths of every value before reading the value itself, and you don't even need to know the length to check the tag and fail if it's unexpected. Very much unlike text-based protocols that require skipping arbitrary amounts of whitespace and reading until you see a delimiter (or an arbitrary limit is reached), dealing with case-insensitivity, comments, etc.

Isn't it notoriously difficult to write a sane, not exploitable asn.1 parser? The openssh didn't want to use x.509 certs for say because they considered asn.1 too risky and difficult iirc.

tialaramex 8y ago

It is notoriously difficult, but to be fair a big part of that notoriety arises in the era when you'd have written this in C, as indeed OpenSSH is written in C. You obviously should not write such software in a language as unsafe as C today. The Distinguished Encoding (DER) used for X.509 forces everything to be unambiguous, so in principle in a language where you can translate that lack of ambiguity into code and not inadvertently have it execute the raw data if you have an off-by-one error this seems no more dangerous than the present use of ASCII. It's just that C has fewer obvious sharp corners when it comes to parsing ASCII and programmers who work mostly in C knew where they were. On the other hand, X.509 is also a scary choice because it's a thicket of options. One of the biggest pieces of work done in the Web PKI has been telling Certificate Authorities not to issue stuff with random options filled out, because that's yet more code surface area to either cause interoperability issues or worse, security problems. For the former, an example is Let's Encrypt. You may notice today your Let's Encrypt intermediate is named X3. What happened to X1 and X2? Well they are created in pairs, so that's why there were more, but it doesn't explain why we're not still using X1. The answer there is that X1 contains a feature called a negative (prohibitive) Name Constraint. This is a way to say in X.509 that the issuer (in this case "DST Root CA X3" operated by Identrust) does not permit this intermediate CA to issue for specific names. Let's Encrypt had a constraint forbidding the US military TLD .mil But Windows XP doesn't understand this optional X.509 feature, if it sees any name constraint that it doesn't understand it concludes that all names are forbidden. So having this constraint meant Let's Encrypt was useless for Win XP clients. Identrust agreed to have Let's Encrypt simply obey this as a policy (and then they subsequently abandoned the policy) to enable XP compatibility. So, avoiding X.509 might have been a sensible choice in OpenSSH but that doesn't necessarily mean using ASN.1 DER would necessarily be a bad choice in new systems today. I don't see any reason to use BER or other encodings of ASN.1 in new systems.

blattimwind 8y ago
With ASN.1 there are also [the relatively new] OER, whose encoding rules seem significantly simpler than the previous ones (but may require transmitting one or the other bit more). W.r.t. parser security, I don't think that has been a success, historically, regardless of format. Few if any parsers for moderately complex formats have had zero vulnerabilities. If you think of a web server, or an XML library, or something similar, chances are pretty good it had at the very least one critical vulnerability related to parsing.

userbinator 8y ago

ASN.1 DER (the variety used for X.509) is IMHO quite easy to parse. It's a TLV (tag-length-value) format, so you know the lengths of every value before reading the value itself, and you don't even need to know the length to check the tag and fail if it's unexpected. Very much unlike text-based protocols that require skipping arbitrary amounts of whitespace and reading until you see a delimiter (or an arbitrary limit is reached), dealing with case-insensitivity, comments, etc.