Re: [TLS] TLS grammar checker?

[Bill Frantz <[e-mail]>]

On 6/18/13 at 5:22 PM, [e-mail] (Blumenthal, Uri - 0558 - 
MITLL) wrote:

>For the software I was talking about - it is finish now, not 
>the start. It's been deployed on multiple platforms since 1995 
>(testing the code included procedure currently called "fuzzing" 
>:). And survived unscathed for several years that I tracked it. 
>Decommissioned by now, I suspect, undefeated as far as I know.

I'm glad to hear this. It is nice to know that there are a few 
things out there that actually work.


>So while I admire the skepticism expressed below, it probably 
>could find a better application. ;).  Not all the computer 
>security is born equal. :)

I fear that we should be designing for something closer to the 
average programmer than for the superior programmer. If I could 
make it idiot proof, I would, but as the saying goes, they keep 
making better idiots.


On 6/18/13 at 5:16 PM, [e-mail] (Nico Williams) wrote:

>Automatic tooling is a better start.  I.e., ASN.1, XDR, IDL, ... compilers.
>
>Ad-hoc syntaxes don't lend themselves to automatic tooling, so they
>tend to result in lots of error-prone hand-coding.

I think this is a good direction. A proof of correctness might 
help since compilers have been known to generate bad code.


>What are you arguing for?  (Mind you, this really isn't the right
>place...  that goes for me too)

What I am arguing for in all security is simplicity. "As simple 
as possible, but no simpler." Complex formats, procedures, 
dependencies, etc. all make it harder to understand what 
security is provided and easier to make mistakes in both 
reasoning and coding.

A long time ago a team from the National Computer Security 
Center (NCSC) came to study KeyKOS, an operating system I was 
working on. We had a fairly simple system which showed potential 
for being evaluated at the B2 level. Someone asked, "What about 
the microcode in the processor and the disk controllers?" The 
answer was basically, "We ignore that."

We are so dependent on so many levels of software and hardware. 
Reducing those dependencies as much as possible, unless we can 
show that additional dependencies make things better, seems like 
a good idea.


>Formats or syntaxes?  Let's be clear.

I not sure what difference you have in mind?


>>While I'm bashing ASN.1, formats that allow infinite length data items are
>>asking for buffer overruns.
>
>Like JSON?  Parsers/decoders need to impose some reasonable limits.
>But this is not where the buffer overflows come from.  The buffer
>overflows I think you're thinking of mostly resulted from redundancy
>in TLV encodings.

I thought there were a few cases of getting the length from the 
ASN.1, doing a malloc and ignoring the failure return and then 
bad things happened(tm). This problem is somewhat like the 
pervasive problem in the early C programming books. They showed 
how simple string processing could be, but left buffer length 
checking as an exercise for the reader. In any case, practical 
parsers need to have some limits on length.

For example, consider RSA keys. 4K keys are the long-normal high 
security keys these days. If each integer is encoded with a 16 
bit length field followed by the integer we would have plenty of 
room for growth without causing memory problems on most platforms.

On the other hand, a 512K RSA integer might be a nifty denial of 
service attack on a server. So we still have to check for 
something reasonable.

---------------------------------------------------------------------------
Bill Frantz        |"Web security is like medicine - trying to 
do good for
408-356-8506       |an evolved body of kludges" - Mark Miller
www.pwpconsult.com |