Protocol implementation errors

[Peter Gutmann]

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 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.

Peter.

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