[langsec-discuss] so what does langsec have to say about heartbleed?
will.sargent at gmail.com
Wed Apr 9 16:34:01 UTC 2014
On Apr 8, 2014, at 4:24 PM, travis+ml-langsec at subspacefield.org wrote:
> So I'm wondering, apart from using buffer-safe languages (which is
> obviously the Right Thing), is there something like taint-checking
> that we could do in programming languages to prevent this sort of
There’s a number of things. Disclaimer: I am not a langsec expert.
Use types heavily. While people know enough that if you have “will.sargent at gmail.com” it’s probably a good idea to provide an Email type rather than passing around a raw string, types provide extra semantic information such as ValidatedEmail that tell you more about characteristics. This applies especially to value objects which do not have internal states. Personally, I think raw types (String, int, etc) are the void pointers of data — not quite as bad as null, but any string you get from outside should come as a UnverifiedString at the very least.
Define a state machine, and watch out for loops.
Bound your collections. If they are unbound, then they are uncontrollable.
Break your programs down into verifiable pieces with inputs and outputs, then isolate them in their own process space. Then use small binary protocols like Thrift to do IPC. DJB pioneered the approach years ago, and it is now seeing a popularization with microservices and the use of Docker / LXC containers.
Rather than write code in C, write code in a decent programming language that can produce C or binary as output.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the langsec-discuss