[e-lang] Re: Protocol implementation errors

Mark S. Miller markm at caplet.com
Sun Oct 5 21:10:20 EDT 2003


At 02:41 PM 10/5/2003  Sunday, Tyler Close wrote:

>On Sunday 05 October 2003 11:03, Jonathan S. Shapiro wrote:
>> Peter:
>>
>> I agree that ASN.1 is statically checkable, and that this is an
>> important property.
>
>What exactly does it mean for a format to be "statically
>checkable"?

Peter's statement was:

At 10:58 PM 10/3/2003  Friday, Peter Gutmann wrote:
>I would say the exact opposite: ASN.1 data, because of its TLV encoding, is
>self-describing (c.f. RPC with XDR), which means that it can be submitted to a
>static checker that will guarantee that the ASN.1 is well-formed.  In other
>words it's possible to employ a simple firewall for ASN.1 that isn't possible
>for many other formats (PGP, SSL, ssh, etc etc).  This is exactly what
>cryptlib does, I'd be extremely surprised if anything could get past that.
>Conversely, of all the PDU-parsing code I've written, the stuff that I worry
>about most is that which handles the ad-hoc (a byte here, a unit32 there, a
>string there, ...) formats of PGP, SSH, and SSL.  We've already seen half the
>SSH implementations in existence taken out by the SSH malformed-packet
>vulnerabilities, I can trivially crash programs like pgpdump (my standard PGP
>analysis tool) with malformed PGP packets (I've also crashed quite a number of
>SSH clients with malformed packets while fiddling with my SSH server code),
>and I'm just waiting for someone to do the same thing with SSL packets.  In
>terms of safe PDU formats, ASN.1 is the best one to work with in terms of
>spotting problems.

Shap wrote:
>> However, ASN.1 is notoriously hard to parse, which leads to errors.
>>
>> I do wonder if we shouldn't design a format that captures the best of
>> both worlds...

Tyler wrote:
>Does the Waterken Doc code format capture the best of both worlds?
>See:
>
>http://www.waterken.com/dev/Doc/code/

If I understand Peter's statement, the answer is yes for Doc, S-Expressions, 
Term trees, XML, Java serialization streams, and many other formats; both 
textual and binary. 

As for Corba IIOP and the CapIDL serialization format, only if the interface 
definition is included. Otherwise, I don't think these are self-describing 
in the sense Peter means.


----------------------------------------
Text by me above is hereby placed in the public domain

        Cheers,
        --MarkM

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list