I've not looked at the discussion in detail, but as far as the dnsmasq code is concerned.
1) Reply UDP packets are truncated to edns_packet_size plus a smallish constant. 2) Malformed packets will not generally be rejected. 3) There's no limit imposed on TCP stream size, other the 2^16 bytes implied by the width of the "size" field in the protocol. Cheers, Simon. On 16/02/16 23:33, Ethan Rahn wrote: > Hello, > > I'd like to ask about how to use dnsmasq to limit the dangers of > CVE-2015-7547. > > This issue was discussed in these links: > > https://googleonlinesecurity.blogspot.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html > https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html > <https://www.google.com/url?q=https%3A%2F%2Fsourceware.org%2Fml%2Flibc-alpha%2F2016-02%2Fmsg00416.html&sa=D&sntz=1&usg=AFQjCNEaOnkLB_utlE1Vs-NmxifGdiyc-A> > > and they suggest using a local resolver ( google specifically mentions > dnsmasq ) to drop these malformed packets. > > What I'd like to understand is what should be set in dnsmasq to actually > limit the UDP size to 512 bytes and the TCP replies to 1024 bytes as > suggested. Or if the packets needed are always malformed and dnsmasq will > always drop them? > > I checked the settings and the only size limit I saw was for > "edns-packet-max", but that doesn't seem like the right setting. > > I tried looking at the code, but I wasn't able to find where the size is > limited and large packets are therefore dropped. I also wasn't able to find > ( by grepping all the instances of "my_syslog" ) a spot where malformed > packets were mentioned. So I'm at a bit of a loss about what to do to > progress further. > > I did use the PoC script provided by Google and was able to see that while > running the test code does cause a segfault, having the test program query > through dnsmasq causes no issues. Since it appears the PoC code uses large > packets to cause the issue ( i.e. 2500 byte UDP packets when we should be > limiting it to 512 per the suggestion ), I'm not 100% convinced that > dnsmasq with it's default settings is the best mitigation to use until > glibc can be updated. > > Thanks, > > Ethan > > > > _______________________________________________ > Dnsmasq-discuss mailing list > [email protected] > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > _______________________________________________ Dnsmasq-discuss mailing list [email protected] http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
