Victor Duchovni <[EMAIL PROTECTED]> writes:

>This, in my view, has little to do with ASN.1, XML, or other encoding
>frameworks. Thorough input validation is not yet routinely and consistently
>practiced by most software developers. Software is almost invariably written
>to parse formats observed in practice correctly, and is then promptly
>declared to "work". 

It's not just this, sometimes the acceptance of not-quite-correct data is
necessary, because if you don't do it, your implementation breaks.  To take
one well-known example, Microsoft have consistently encoded the version info
in their SSL/TLS handshake wrong, which in theory allows rollback attacks.  So
as a developer you have the following options:

 1. Reject the encoding and be incompatible with 95(?)% of *all* deployed SSL
    clients (that's *several hundred million* users).

 2. Turn a blind eye and interoperate with said several hundred million users,
    at the expense of being vulnerable to rollback attacks.

I'm not aware of a single implementation that takes option 1, simply because
it would be pure marketplace suicide to do so.

The same goes for pretty much every other security protocol I know of.  SSH is
the most explicit since clients and servers exchange ASCII strings before they
do anything else, all SSH implementations have a built-in database of known
bugs that they adjust their behaviour for when they detect a certain client or
server.  Obviously no-one will implement this bug-compatibility for a security
hole, but it's not impossible that some of this extended flexibility may at
some point lead to a problem.

For other protocols, it works in reverse, you recognise the peer implemention
by the bugs, not the other way round.  Beyond straight implementation bugs
though are standards that require insecure or ambiguous behaviour, either by
accident (which eventually gets fixed), or because of design-by-committee
politics, about which enough has probably been said in the past
(cough*IPsec*cough :-).


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

Reply via email to