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

[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>

On Thu, Feb 18, 2016 at 2:35 PM, Rick Jones <rick.jones2 at hpe.com> wrote:

> On 02/18/2016 10:24 AM, Louis Munro wrote:
>
>> This is what I have come up with for now:
>>
>> 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
> 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/20160218/029aaa34/attachment-0001.html>