6

As far as I can tell, .NET doesn't have an ASN.1 parser for reading or writing data built in the framework. This means that any code that creates or verifies ASN.1 data is using a 3rd party library of varying quality. Bouncy Castle, and JavaScience for .NET are a few examples of such libraries.

I'm aware of a few production installations that use less widely used, and less tested ASN1 parsers. Considering the problems of parsing data in the past, and also that OpenSSL is still having ASN1 parsing issues I think that ASN1 parsing is a overlooked concern.

Background

ASN.1 is used in TLS certificates, X.400 electronic mail, X.500 and Lightweight Directory Access Protocol (LDAP) directory services, H.323 (VoIP), Kerberos, BACnet and Simple network management protocol (SNMP) to describe the Protocol data units (PDU) they exchange. Any custom software that reads or writes ASN.1 data outside of a trusted wrapper could expose the system to risk.

See Wikipedia for more information.

Question

  • How do I test and secure ASN.1 Parsers?

  • What parsers are more secure than others?

  • How does .NET do AD LDAP, Certificate oid validation, and kerberos without a built in library?

Community
  • 1
makerofthings7
  • 50,090
  • 54
  • 250
  • 536

3 Answers3

3

You cannot really test an ASN.1 parser for correction, because it is a complex piece of software and we do not know how to prove that a given piece of software is correct. What you can do is rely on a library with good repute. You might want to have a look at this question. Alternatively, reimplement it yourself; this is not very hard if you stick to a workable subset of ASN.1 (e.g. only DER encoding, only a few string types,...).

.NET necessarily has some built-in code for doing ASN.1 parsing; this does not mean that it necessarily gives you access to that library.

At least, ASN.1 libraries written in Java or a .NET language benefit from the innate resistance of these languages to buffer overflows (if a buffer overflow occurs, an exception is thrown, which is marginally better, from a security point of view, to actually overwriting data in memory).

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
0

I think ASN.1 encoder/decoder can be generated automatically from a formal description of the format, and thus should be relatively safe from (programming) faults. Check ASN.1 compilers. You can also search for ASN.1 in the MITRE CVE database and check how common such flaws are and who does them. Or if a library like bouncy castle in general has a tendency for such flaws, compared to, e.g., OpenSSL. I think the risk is very low, I only know of one such incident.

pepe
  • 3,536
  • 14
  • 14
0

What is your ability when it comes to parsing. Which is really what we're talking about in general, if you want to be able to validate ASN.1, luckily since there is an EBNF definition for ASN.1 it would be a lengthy project but you could use any of the LALR Parser frameworks to help generate the code.

You would basically be recreating the library.

I'm not certain what you mean by secure. A valid PDU would conform to ASN.1. But you are looking at a different problem if you want to limit the type or amount of data that can be asked for using this method. Only thing I can really say is the more popular libraries probably have had a little higher scrutiny, ultimately only part of the overall system that you will be deploying.

M15K
  • 1,182
  • 6
  • 7