[e-lang] Re: Protocol implementation errors

Bill Frantz frantz at pwpconsult.com
Fri Oct 10 21:29:25 EDT 2003


At 5:36 PM -0700 10/5/03, Norman Hardy wrote:
>I can't recall Keykos security problems stemming from hostile message
>strings in a key invocation.
>I don't know why. Perhaps we always expected hostile messages as a
>cultural thing.

I think there were several additional reasons for this:

* Most of the strings passed were very simple, consisting of just one
string.  We didn't get much more complex than, for example, the record
collection (which used byte string names to look up data and capabilities).
Its string was:

  * 1 byte - length of name
  * n byte (0-255) name
  * the rest data.

* We did not try to handle "infinite length" strings.  In general, strings
were limited to 4096 bytes.

* We were programming in 370 assembler, which, IMHO, is better suited to
writing secure code than C.  For example, the string copy primitive in C is
strcpy, where the source string determines the length.  In 370 assembler,
the primitive is MVCL (move long) which takes 5 parameters, the source
address and length, the destination address and length, and the fill
character.  Having to specify those 5 parameters made the issues involved
in a string copy very obvious each time one was coded.

* We did not, as a general rule, have a stack.  As a result, it was less
likely to have program control data (return addresses) and buffers next to
each other, where a buffer overrun could result in both hostile code, and
the necessary changes to the program control data to pass control to it.


At 10:58 PM -0700 10/3/03, 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.

I think Peter has convinced me that ASN.1 (by which I mean DER
specifically, since that is the form that the run-time code parses), is
probably not a whole lot worse than the other formats (which also have
shown significant parsing bugs).  While some of the problems come from the
details of the format, most probably come from the complex data structures
that are part of the problem space.  Given that this is a correct
assessment, then we need to think of ways to protect ourselves against the
programs that parse these data.

If we were coding in KeyKOS or EROS, I would put the parsing code in a
separate domain.  To protect against denial of service that domain would
have a limited space bank, a keeper, and a timeout to signal parse failure
to the caller.  To guard against attack, that domain would only have
capabilities to:

* The input string and/or the input byte stream
* "No hole" creators for the output objects.

Further protection can be built by limiting the privilege of the domains
that use these output objects.  (Note that the cost of a domain call is
very small compared with the cost of a public key operation.)

I don't really know how to apply this approach to a UNIX like system.  I
think for these systems, it might be best to write the parsing code in a
"safe" language such as Java, Smalltalk, E, Scheme etc.  That would result
in an additional layer of protection from the runtime.  If the cost of
calling into and return from the language is small enough, the extra cost
of the language should be tolerable.  (Having to fire up a Java Virtual
Machine each time could make public key operations look fast.)

Cheers - Bill



-------------------------------------------------------------------------
Bill Frantz        | "There's nothing so clear as a | Periwinkle
(408)356-8506      | vague idea you haven't written | 16345 Englewood Ave
www.pwpconsult.com | down yet." -- Dean Tribble     | Los Gatos, CA 95032


_______________________________________________
e-lang mailing list
e-lang at mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang

-------------------------------------------------------------------------
Bill Frantz        | "There's nothing so clear as a | Periwinkle
(408)356-8506      | vague idea you haven't written | 16345 Englewood Ave
www.pwpconsult.com | down yet." -- Dean Tribble     | Los Gatos, CA 95032


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



More information about the cryptography mailing list