[Dnsmasq-discuss] CVE-2015-7547 tcp path mitigation hack

[s***@binnacle.cx]

UDP path mitigation covered by

edns-packet-max=512

Ugly but effective TCP fix:


--- src/forward.c.orig 2011-02-17 10:30:15.000000000 -0500
+++ src/forward.c 2016-02-17 23:16:03.792233438 -0500
@@ -966,14 +966,17 @@ unsigned char *tcp_request(int confd, ti
/* In case of local answer or no connections made. */
if (m == 0)
m = setup_reply(header, (unsigned int)size, addrp, flags, daemon->local_ttl);
}

check_log_writer(NULL);

+ /* mitigate CVE-2015-7547, truncate beyond 1023 bytes */
+ m &= 0x3FF;
+
c1 = m>>8;
c2 = m;
if (!read_write(confd, &c1, 1, 0) ||
!read_write(confd, &c2, 1, 0) ||
!read_write(confd, packet, m, 0))
return packet;
}

[Jim Alles]

I am putting together a 'how-to' document to leverage dnsmasq to mitigate
the risk of this CVE, in a router product known as Untangle Next Generation
FireWall (NGFW) - another brand of bandaid, I suppose ;)

I would appreciate a review of these steps:
1) Override the upstream DNS server on the router to OpenDNS.
https://engineering.opendns.com/2016/02/17/2980/

2) Using input filter rules, block TCP port 53. This protects dnsmasq.

3) Add a configuration line into dnsmasq.conf of: 'edns-packet-max=1023'
(rationale: two responses cannot overflow the 2048 buffer).

2) Assign DNS to the clients using the router(gateway) IP address that runs
dnsmasq (generally by DHCP) and using that LAN address in both primary &
secondary assignments.

3) Using forward filter rules, block TCP/UDP port 53 on the external
interface (WAN). This does not impact dnsmasq. It would be a good idea to
wait until all of the clients' DHCP lease have renewed.

Now, clients behind the firewall can only get DNS answers from dnsmasq.
Services that depend on edns0 like DNSSEC; or IPv6 are likely to be
negatively affected by this type of 'shield'.

Question:

regarding Simon's point 2) Malformed packets _will_not_ generally be
rejected.
can you confirm that, and elaborate?

Do you think Google's success was based mainly on limiting edns-packet-max?

Do you think it is too much to expect dnsmasq to act as a shield for this
exposure?

Thanks,

Jim Alles
disclaimer: I do not represent Untangle, and this concept remains my own,
anyone who takes it is then responsible for any consequences, good or bad
(tag - you're it).



This email has been sent from a virus-free computer protected by Avast.
www.avast.com <https://www.avast.com/sig-email>
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

iptables -I INPUT -p tcp -m tcp --sport 53 -m length --length 1024:4096
-j DROP
iptables -I INPUT -p udp -m udp --sport 53 -m length --length 1024:4096
-j DROP
4096 is really just some large number here.
I could go higher if jumbo frames might be involved.

Generic Receive Offload (GRO) may be sufficient to get larger segments
even without JumboFrames. If you want duct-tape added to the belt and
suspenders, you might consider taking it out to 65535 - I'm pretty sure
that nothing will "GRO" beyond that size.
Of course, this is a band-aid solution.

There is no substitute for updating glibc in the end.

Indeed.
But I digress, this is getting off track and is not really relevant to

this list.

Perhaps, but it does go to how long one might be expected to carry along
bandaids/kludges in the likes of dnsmasq.
rick jones
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss