[Cryptography] "NSA-linked Cisco exploit poses bigger threat than previously thought"

[Jerry Leichter]

>> Buffer overflows.  How are we *still* fighting buffer overflows?
> 
> I'm looking for a chance to learn Rust. (Even makes writing multi-thread programs sensible projects.)
We've had safe programming languages for quite some time, but this kind of code continues to be written in C.  C itself is what it is - inherently unsafe - but in fact hardly anyone writes in C alone:  They write in a language defined by C and a bunch of standard libraries.  Those libraries contain many functions that cannot be used safely (gets(), banned from recent libraries; sprintf()) or are extremely easy to use in hazardous ways.  The improved versions - which, for example, require you to pass in the length of an output buffer you provide, rather than just a raw pointer to a "large enough" buffer - are a huge improvement, but they still require that the programmer pass in the right length.

And when it comes to buffer manipulation - e.g., using read() and write() safely - you always end up rolling your own.

I'm thinking of something like a "safe buffer" struct that would have an internally set size.  The provide a wrapper around read() that takes one of these safe buffers and makes sure it doesn't overflow it.  If the buffer operations keep track of what bytes in the buffer have been written to (presumably only as an upper limit, with everything below that having been written to) then a write() wrapper would refuse to send data that hadn't been marked as written to - avoiding the particular bug that appears to have been exercised in the Cisco attack.

                                                        -- Jerry