nail

> I guess they’ve seen one too many bugs from precedence confusion. Yep. I just filed a precedence bug at https://github.com/jbangert/nail/issues/7 for Nail, which is a security-concious project. (It was presented at LangSec 2014). > It doesn’t have dependent types. Yep. Programming language theorists love type systems, and dependent types are one way to prove bounds safety, but they're not the only way. Puffs is an imperative language, not functional (for the reasons described in https://github.com/google/puffs/blob/master/doc/related-work...). With mutable state, a Puffs variable's within-bounds-ness can change over that variable's lifetime, but its type does not. > There is limited effect typing: functions can be marked pure, impure (!), or impure coroutine (?). Yep. That's the current design, although I'll probably revise that based o

Verifying length fields is absolutely a parser issue. Heartbleed and similar bugs arise from the fact that the length is encoded (at least) twice -- once, in the explicit length field, once implicitly in the length of the transmitted data (i.e. the TCP packet length). If multiple copies of the same redundant information are not identical, then that is definitely a case of invalid input. I try to address this class of parser vulnerability with my Nail parser generator (OSDI '14 , github.com/jbangert/nail ), which is inspired by Meredith's hammer.

Amusing name given the (coincidental?) existence of Nail [0][1] [0] [PDF] https://people.csail.mit.edu/nickolai/papers/bangert-nail-la... [1] https://github.com/jbangert/nail

I think you shouldn't write parsers by hand at all and instead generate them automatically -- without semantic actions. I wrote a parser generator for tricky binary formats a few months ago - https://www.usenix.org/system/files/conference/osdi14/osdi14... and there's a paper explaining it here https://github.com/jbangert/nail

My one experience with the Tox project was that I made a few (I thought) constructive suggestions. First, I suggested they use some form of static analysis or perhaps a 'safer' language to implement their core functionality - such as Rust or Go, instead of rather messy (at the time) C code. Furthermore, having spent a lot of time researching parsers and how parser differentials can affect the security of systems, I suggested they use some tools, such as protocol buffers, to eliminate handwritten parsing code. The response I got was rather disheartening and downright hostile - it boiled down to the fact that protocol buffers involves C++ code which they are a priori against, without actually engaging in a factual argument (I wrote an article in the current USENIX login/ last years OSDI about parsers for binary protocols for anyone intere

One issue with PEG's (and other parsers) is that it doesn't address (unbounded) count fields (or bounded count fields in an elegant manner) or offsets. This means a pure PEG can't express e.g. PDF or ZIP files. To address this, we built a PEG-based parser generator with a few new features, Nail (paper at OSDI 14, github.com/jbangert/nail)