5 ms·

This root cause analysis matches up with my experience. You can absolutely have safe ASN.1 with ASN.1 compilers, but the implementations that star in these vuln

This root cause analysis matches up with my experience. You can absolutely have safe ASN.1 with ASN.1 compilers, but the implementations that star in these vulnerabilities tend to be generic or ad-hoc DER/BER parsers. You'd be hard-pressed to be able to blame ASN.1 with XER (XML Encoding Rules) encoding since then you'd throw an XML parser at the problem, side-stepping the bit twiddling and exchanging it for XML parsing bugs instead. Similarly, if all you have is fixed-length items, OER (Octet Encoding Rules), you essentially get a formally specified struct with a well-defined way to go from there to XML or JSON with JER (JSON Encoding Rules). I imagine we'll see this happen with CBOR (whose ASN.1 equivalent is technically CDDL) a few years down the road.

riedel 5y ago
I think the root cause of this is that ASN.1 is deemed uncool and it is difficult to implement a standard compliant FOSS compiler for all the encodings. I was surprised doing research into binary XML and JSON how far you get with ASN.1 . However, the ecosystem seems so discoupled from anything else that there is rarely an implementation path for a quick win beyond mentioned hacky parsers that are both error prone and inefficient or purchasing some obscure commercial complier as I remember. Edit: would be really happy to see some good open source compilers with extensible encoding support being listed here
- rdpintqogeogsaa 5y ago
  > Edit: would be really happy to see some good open source compilers with extensible encoding support being listed here I think that's the reason of ASN.1 being trapped in a very restrictive space. From Olivier Dubuisson's ASN.1 -- Communication between Heterogeneous Systems, p. 86 et seq. talking about use of ASN.1 by the IETF: > the definition of many macros and macro instances to represent semantic links instead of information object classes and information objects although no ASN.1 compiler properly takes into account the macro concept (on the other hand, no compiler of the public domain does with the information object class concept unfortunately); In essence, ecosystem failure due to a non-existent overlap of the telecom industry (full of commercial and expensive solutions) and the Internet community (working in a standards committee that tracks pre-existing permissionless innovation distributing the standards at no cost, strongly affiliated with free software ideas) caused ASN.1 to fall by the roadside. Now that ASN.1 is considered uncool, the ecosystem certainly won't be coming anymore, so we'll be forced to reinvent ASN.1, probably re-learning every lesson along the way.
  - rusk 5y ago
    > we'll be forced to reinvent ASN.1 I think this already happened with Google Protocol Buffers
  - kortex 5y ago
    > In essence, ecosystem failure due to a non-existent overlap of the telecom industry (full of commercial and expensive solutions) and the Internet community (working in a standards committee that tracks pre-existing permissionless innovation distributing the standards at no cost, strongly affiliated with free software ideas) caused ASN.1 to fall by the roadside. Yep. I think this is the crux of the matter. I don't even think it is an "uncool" thing. In a word, IMHO it's too "closed". Xml is not exactly hip, but I can find high scoring python xml libraries on snyk.io. I know that is not a very scientific metric but it's a good proxy for a bunch of things that are hard to measure. I think even if it were "cool", it would be a struggle to get a culture to nucleate. It has the same vibe as codecs: complex, kinda arcane, too closely associated with closed source, litigious, corporate culture. It doesn't help that it is guilty by association with numerous poorly written libraries. Unless that is what you mean by "uncool". Now that there is cbor, msgpack, cap'n proto, protobuf, thrift, and a bunch others (just in the binary space), asn.1 would have to make a really compelling argument to win out. It would need a lot more than coolness.
- XAMPPRocky 5y ago
  > would be really happy to see some good open source compilers with extensible encoding support being listed here This is a shameless plug, and not a compiler per se, but it's pretty close[0]. It's a codec framework for ASN.1 in Rust similar to `serde` for other formats if you're aware of that. It uses Rust's traits to define seperate layers for the codec model, and the encoding rules, allowing you to have one model used with many encodings, and share one decoder & encoder for all models. Extensibility just uses the regular Rust `#[non_exhaustive]` attribute. It doesn't support formats like A/UPER yet, but that is coming in the next year. :) [0]: https://github.com/XAMPPRocky/rasn https://github.com/XAMPPRocky/rasn
  - riedel 5y ago
    Thanks, rasn looks really promising!! What are the projects this is used in? How easy is it to use as a codec layer from other programming languages?
    - XAMPPRocky 5y ago
      > What are the projects this is used in? I don't know of any third-party projects that are using it, though from talking to users and looking at the download numbers there are quite a few, they're just closed-source. You can look at the dependent downloads[0] to get an idea of whose using the implementations included with rasn. > How easy is it to use as a codec layer from other programming languages? It's as easy as using any Rust code from other programming languages. Rasn is completely IO-agnostic, it works entirely using byte slices (`&[u8]`). So all that should be required is writing a C-friendly layer if doing this by hand, or using a language specific binding library like PyO3 to generate more friendly bindings. [0]: https://crates.io/crates/rasn/reverse_dependencies https://crates.io/crates/rasn/reverse_dependencies

riedel 5y ago

I think the root cause of this is that ASN.1 is deemed uncool and it is difficult to implement a standard compliant FOSS compiler for all the encodings. I was surprised doing research into binary XML and JSON how far you get with ASN.1 . However, the ecosystem seems so discoupled from anything else that there is rarely an implementation path for a quick win beyond mentioned hacky parsers that are both error prone and inefficient or purchasing some obscure commercial complier as I remember. Edit: would be really happy to see some good open source compilers with extensible encoding support being listed here

rdpintqogeogsaa 5y ago
> Edit: would be really happy to see some good open source compilers with extensible encoding support being listed here I think that's the reason of ASN.1 being trapped in a very restrictive space. From Olivier Dubuisson's ASN.1 -- Communication between Heterogeneous Systems, p. 86 et seq. talking about use of ASN.1 by the IETF: > the definition of many macros and macro instances to represent semantic links instead of information object classes and information objects although no ASN.1 compiler properly takes into account the macro concept (on the other hand, no compiler of the public domain does with the information object class concept unfortunately); In essence, ecosystem failure due to a non-existent overlap of the telecom industry (full of commercial and expensive solutions) and the Internet community (working in a standards committee that tracks pre-existing permissionless innovation distributing the standards at no cost, strongly affiliated with free software ideas) caused ASN.1 to fall by the roadside. Now that ASN.1 is considered uncool, the ecosystem certainly won't be coming anymore, so we'll be forced to reinvent ASN.1, probably re-learning every lesson along the way.
- rusk 5y ago
  > we'll be forced to reinvent ASN.1 I think this already happened with Google Protocol Buffers
- kortex 5y ago
  > In essence, ecosystem failure due to a non-existent overlap of the telecom industry (full of commercial and expensive solutions) and the Internet community (working in a standards committee that tracks pre-existing permissionless innovation distributing the standards at no cost, strongly affiliated with free software ideas) caused ASN.1 to fall by the roadside. Yep. I think this is the crux of the matter. I don't even think it is an "uncool" thing. In a word, IMHO it's too "closed". Xml is not exactly hip, but I can find high scoring python xml libraries on snyk.io. I know that is not a very scientific metric but it's a good proxy for a bunch of things that are hard to measure. I think even if it were "cool", it would be a struggle to get a culture to nucleate. It has the same vibe as codecs: complex, kinda arcane, too closely associated with closed source, litigious, corporate culture. It doesn't help that it is guilty by association with numerous poorly written libraries. Unless that is what you mean by "uncool". Now that there is cbor, msgpack, cap'n proto, protobuf, thrift, and a bunch others (just in the binary space), asn.1 would have to make a really compelling argument to win out. It would need a lot more than coolness.
XAMPPRocky 5y ago
> would be really happy to see some good open source compilers with extensible encoding support being listed here This is a shameless plug, and not a compiler per se, but it's pretty close[0]. It's a codec framework for ASN.1 in Rust similar to `serde` for other formats if you're aware of that. It uses Rust's traits to define seperate layers for the codec model, and the encoding rules, allowing you to have one model used with many encodings, and share one decoder & encoder for all models. Extensibility just uses the regular Rust `#[non_exhaustive]` attribute. It doesn't support formats like A/UPER yet, but that is coming in the next year. :) [0]: https://github.com/XAMPPRocky/rasn https://github.com/XAMPPRocky/rasn
- riedel 5y ago
  Thanks, rasn looks really promising!! What are the projects this is used in? How easy is it to use as a codec layer from other programming languages?
  - XAMPPRocky 5y ago
    > What are the projects this is used in? I don't know of any third-party projects that are using it, though from talking to users and looking at the download numbers there are quite a few, they're just closed-source. You can look at the dependent downloads[0] to get an idea of whose using the implementations included with rasn. > How easy is it to use as a codec layer from other programming languages? It's as easy as using any Rust code from other programming languages. Rasn is completely IO-agnostic, it works entirely using byte slices (`&[u8]`). So all that should be required is writing a C-friendly layer if doing this by hand, or using a language specific binding library like PyO3 to generate more friendly bindings. [0]: https://crates.io/crates/rasn/reverse_dependencies https://crates.io/crates/rasn/reverse_dependencies