They're mostly DoSes, which rank a bit less as a vulnerability. If I know a world leader is going to a city and call in a bomb threat, yeah I disrupted things but it's a rather qualitatively different attack.
These don't seem to be directly in the ASN.1 code, but the consumer of such code, right? (Apart from the boolean compare?) That's probably just the result of having complicated structures to deal with, and no type system to tell you when you've made a bad assumption. And even with a good type system, you can still opt-in to explicitly failing. Code like "let x = foo.Value.bar // foo must have a value at this point" isn't totally uncommon. You can statically analyze and know which points will fail at runtime, but without exceptions, if any logic error counts as a vulnerability (because it kills the process), then we're basically saying the bar is perfect code, right?
With exceptions you'd just wrap the whole thing up and catch any such logic errors and save the process and destruct the socket. It seems like that'd have been a mitigation here (assuming structures aren't reused and sockets are exception safe).
No, the vulnerabilities are in the ASN.1 code, in places like libssl/src/crypto/asn1/a_set.c, tasn_dec.c. There's also stuff in the PKCS 7 and X.509 code, but that code is still very much ASN.1 code, since it contains handwritten coders and decoders for PKCS 7 and X.509 (the asn1 directory contains the code for the generic types, like INT, SET, STRING, etc.). There's also some weird stuff, like an X509 time comparison functions in x509_vfy.c that is like the ones in asn1/a_XXXtime.c.
Now now, there's an LL(1) parser for ASN.1, and it's easily found in the following reference:
Fouquart (P.), Dubuisson (O.) and Duwez (F.). - Une analyse syntaxique d'ASN.1:1994. - Internal Report RP/LAA/EIA/83, France Télécom R&D, March 1996. Only in French
In the first place, LL(1) parser for BER/DER is mostly trivial exercise, although somewhat tedious.
Problem with ASN.1 is not with the specification itself but mostly in the fact that many people want to parse BER/DER with code that directly populates some application-specific data structure and depends on ASN.1 syntax of what they expect to parse. With that you invariably get very complex interface between parser library and application where both components have to handle various special cases correctly (to the point that the whole thing is not even leaky abstraction, because it almost isn't abstraction at all).
