Protocol implementation errors

[Markus Friedl]

On Sat, Oct 04, 2003 at 05:58:49PM +1200, Peter Gutmann wrote:
> Bill Frantz <frantz at pwpconsult.com> writes:
> 
> >This is the second significant problem I have seen in applications that use
> >ASN.1 data formats.  (The first was in a widely deployed implementation of
> >SNMP.)  Given that good, security conscience programmers have difficultly
> >getting ASN.1 parsing right, we should favor protocols that use easier to
> >parse data formats.
> >
> >I think this leaves us with SSH.  Are there others?
> 
> 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 don't think so.  The SSH packet format is _much_ simpler than ASN.1
and neither the original ssh-1.x nor OpenSSH had problems due to
the packet parsing, both have been immune to last years malformed
packet tests.   I've seen more problems related to ASN.1 parsing
than to SSH packet parsing...

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