[Dnsmasq-discuss] How to use dnsmasq to mitigate dangers of CVE-2015-7547?

[Ethan Rahn]

Simon,

Thanks for the response. I appreciate your insights on this.

I understand that you may not want to go into how dnsmasq would interact
with glibc, but I would like to try and understand this a bit better. I'm
going to think out loud below. Please correct me if I'm horrendously off
track.

Using edns_packet_size to limit the UDP size to 512 bytes will prevent the
issue with the first response buffer being filled up. This will in turn
prevent the normal attack that they describe and carry out in the proof of
concept code by failing to meet the criteria for the first response filling
up the buffer send_dg creates. It will not prevent the timing attack.

In the normal case libresolv.so ( at least in linux ) will always use UDP
to resolve a query, and getaddrinfo() will end up using libresolv.so so
linux users in the general case shouldn't have to worry about the TCP
attack if dnsmasq is handling all their dns queries.

So to conclude using edns_packet_size = 512 to limit the size of the
response is the solution to resolving this for programs that use
getaddrinfo() to resolve a DNS query? Or one could set a firewall rule
outside of dnsmasq to drop UDP DNS replies greater than 512 bytes?

Thanks,

Ethan

On Wed, Feb 17, 2016 at 7:55 AM, Simon Kelley <simon at thekelleys.org.uk>
wrote:

> 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
> > Dnsmasq-discuss at lists.thekelleys.org.uk
> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20160217/1a9b8525/attachment.html>