Travis H. wrote:
> Actually, encoding lengths of other fields in a
> protocol is probably the easiest way to introduce a
> remotely-exploitable vulnerability (typically buffer
> overflow).  I'm going to have to side with the "no
> redundancy means no inconsistencies possible" argument
> here.  Oh, and you shouldn't process
> remotely-manipulable data in a language like C, unless
> you're doing all variable-length buffer management
> through a well-tested library, and even then you're
> playing with fire.

All fields that could be controlled by an adversary
should have reasonable maximum values specified in the
protocol definition.  Consider the language field in
HTTP.  It normally is blank, or contains the string
"English".  A lot of implementations failed in ways
interesting to attackers when the language field
exceeded 20K, and wound up executing script contained in
the language field.  Why were language fields not given
a reasonable maximum length, and reasonable limits on
the characters permitted in the language field, and an
error response defined for the case that the language
field exceeded that limit, or contained improper

The only fields that should be permitted to have
unbounded length are those that can be pipelined, where
you repeated fill a fixed length buffer, and repeatedly
empty it.

> And fixed-length buffers are often broken too, because
> many a programmer has arbitrarily decided "that's big
> enough" without considering how an active adversary
> would be constrained, or without considering that the
> data may grow in size with the next revision of
> (whatever is feeding data to us).

All fixed length buffers are of course broken unless the
length is part of the protocol.  Since there is, in
practice, always going to a maximum length, if only the
length at which the computer starts to run out of
memory, maximum lengths should be defined as part of the
protocol "The xxxx field is bounded by the first
whitespace character, or a maximum of 128 unicode
characters, whichever comes first."

Recall all the implementations that gave interesting
results when the length count overflowed to negative.

         James A. Donald

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to