-- 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 characters? 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. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG /qepotdogioqKl6zqKb1307bOmyXeRzSTpBPmWcw 4WtThf8IVl9id73YCBhzL8jl5yJ7wd+oc/GuW4E7o --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]