,
9 tweets,
2 min read
Read on Twitter
I'm going to annoy @sergeybratus by defending this as good practice. Masscan, a simple portscanner, has 2 separate ASN.1 parsers.
2/ "ASN.1 parsers" is a poster child of the problem of "parsing", taking external network-protocols/file-formats and converting them to some internal structure. There are tons of buffer-overflows in these things, since every field is an arbitrarily long buffer.
3/ But it's not necessarily the parser's fault. A bunch of the "parsers" problems are not in the parsers themselves, but the caller of the parser that's given an unexpectedly long buffer.
4/ Such was the case in the ASN.1 buffer-overflow I found in the ICCP protocol during a pentest of a powergrid. The parser was technically fine, it's just the the user of the parser didn't check the buffer length it got from the parser.
5/ So anyway, masscan has two different ASN.1 parsers that are radically different. One is the SNMP parser based on having the entire reassembled UDP packet available. The other is the X.509 parser which assumes a stream of unassembled bytes arriving over TCP.
6/ The "X.509" parser is sufficiently generic that it's also used for the SMB "NTMLSSP" ASN.1 parser, but it's fairly raw, so you could argue 'masscan' has three ASN.1 parsers instead of just two.
7/ What this is supposed to demonstrate is that there's no such thing as a generic ASN.1 parser that is good for all possible uses. Instead, it's appropriate to have different parsers for different purposes.
8/ It would be good to minimize the number of ASN.1 parsers in the Linux kernel, but the minimal number is going to be greater than one. But that's just the principle that it's best to refactor into common libraries, not a question of parser dangers.
9/ A common mistake when refactoring is trying to create one library for a set of related tasks, focusing too much on the commonality believing one library is appropriate, rather than appreciating the differences making it inappropriate.
