[Cryptography] TLS2

James A. Donald jamesd at echeque.com
Tue Oct 1 19:28:55 EDT 2013


On 2013-10-01 14:36, Bill Stewart wrote:
> It's the data representations that map them into binary strings that 
> are a
> wretched hive of scum and villainy, particularly because you can't 
> depend on a
> bit string being able to map back into any well-defined ASN.1 object
> or even any limited size of ASN.1 object that won't smash your stack 
> or heap.
> The industry's been bitten before by a widely available open source 
> library
> that turned out to be vulnerable to maliciously crafted binary strings
> that could be passed around as SNMP traps or other ASN.1-using messages.
>
> Similarly, PGP's most serious security bugs were related to
> variable-length binary representations that were trying to steal bits
> to maximize data compression at the risk of ambiguity.
> Scrounging a few bits here and there just isn't worth it.
>
>

BER and DER can express an arbitrary data structure - and thus can crash 
the program receiving the data, probably causing it to execute 
transmitted data as code.

The same, however, is true of every overly general line format. Incoming 
data should be parsed as the expected and bounded size data structure, 
thus we need something that can generate parsing code from a description 
of the data at compile time.  We need compile time descriptions of the 
data, not run time descriptions, because the program that uses the 
incoming data will unavoidably rely on compile time description of the data.

PER, however cannot receive unexpected data structures.

Thus all data should be transmitted as PER, or by a format with the 
properties of PER.




More information about the cryptography mailing list