Re: [Acme] ACME or EST?

[Christian Huitema <[e-mail]>]

> One of the many reasons to drop ASN.1, particularly the Deranged Encoding Rules.
>
> The type of coding error that comes up is as follows:
>
> Tag Length[ Tag Length [Value]]
>
> Lets say each atom has a length of 1 byte, this would be coded
>
> xx 03 xx 01 xx
>
> Now what happens if the coder is wrong and instead gives:
>
> xx 99 xx 01 xx
>
> Buffer overrun error time!

On the other hand, there is enough information in the BER/DER encoding to perform run time verifications and avoid these overruns. It falls in the general category of "never trust input received from the network."

You can find this kind of errors with pretty much any "variable length" format. If you have explicit length coding, then you must check the consistency of the stated length with the message buffer. If you have implicit coding, e.g. using some kind of delimiter, you must checks that delimiters happen before the end of the message.

Then, there is all the fun related to integer overflow, especially when the syntax uses element counts rather than element length. Or stack overflow if the decoder uses recursion. Remember the attacks using "specially crafted JPEG images?"

I am not sure that the message description language matters very much, the quality of the implementation matters much more. And, as far as protocol go, better keep the syntax as simple as possible. But you are right about the level of "exotic complexity" in ASN.1. It does not help.

-- Christian Huitema