I’ve been working a DNS server. I mention this because it's Langsec compliant: it parses DNS packets, and zonefile records, before processing them. It's complete as far as DNS protocol is concerned: it reads zonefiles and responds to DNS queries correctly. It's still incomplete for other features, such as updating configuration/zonefiles while running. It's completeness is a good evidence that Langsec is practical rather than theoretical.
I point this out because both “Hammer” and “Nail” only partly parse DNS packets. They leave out the difficult bit of DNS name compression. This isn't a valid test -- every protocol/format is going to have difficult bits, they really need to demonstrate how they'd handle name compression. The correct answer, btw, is to 'punt': it's so specific to DNS that no system can automate it. The Nail paper claims they can reduce “by an order of magnitude” the 10k lines-of-code in djbdns. This is false, because only a tiny bit of code is involved in parsing. My DNS server is 16k lines-fo-code, but fewer than 200 parse DNS packets -- and that includes name compression. My DNS server focuses on speed. It’s about 10 times faster than any other DNS server, and close to 100 times faster than BIND9, doing 10 million queries/second. The paper that Peter, Sergey, and I collaborated on: you can do both Langsec and also be very fast. I parse DNS zonefiles faster than ‘wc’ can count the number of words in them, which I think is a pretty interesting result. (I'm still not clear on why 'wc' is so slow). The converse argument is that if you aren’t fast, then why are you insecure? C/C++ is inherently insecure. My C code is faster than what can be written in Java, but if your C code isn’t, then why aren’t you writing in Java? In any event, the new AddressSanitizer feature in gcc/clang means that I may get the benefit of a high-level language for only a 2x slowdown – meaning my sanitized C may be faster than their dangerous C. This then has implications for Nail/Hammer: if they have too high a performance cost, slowing C program down to Java speeds, then that questions their usefulness. Meredith moved to an “arena allocator” for this reason – relying upon normal malloc() would’ve killed performance. (The rule for parsing is that you should have zero malloc()s when parsing a packet). My server parses before processing the packets and zonefile records, but that doesn’t make it immune from Langsec attacks. Consider a wild card record in a zonefile like “*.example.com”, then a query for a domain with a lot of labels “a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.example.com”. Instead of looking up the name directly in one step, I have to step-by-step remove the labels looking for a wildcard match. Thus, recognized valid input can nonetheless control a vast amount of processing. I’ve got some creative solutions to partially mitigate this problem, though I wonder how others solve it. By the way, the parser for packets is here: https://github.com/robertdavidgraham/robdns/blob/master/src/proto-dns-parse.c#L131 One thing to note is that I fully validate a compressed DNS name before extracting it. Thus, when you look at the “extract” function, it has zero protection against attacks -- either I trust the "recognizer" or I don't.
_______________________________________________ langsec-discuss mailing list langsec-discuss@mail.langsec.org https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
