OpenWrt Forum Archive

Topic: CVE-2015-7547 - is openwrt affected?

The content of this topic has been archived on 23 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Openwrt does not use glibc. Its uclibc and musl based

can someone help to create a firewall rule that drops UDP DNS packets > 512 bytes

maurer wrote:

can someone help to create a firewall rule that drops UDP DNS packets > 512 bytes


Possible using 'connbytes'  extension : http://ipset.netfilter.org/iptables-extensions.man.html
But really bad idea. DNS queries are not just getting "1.2.3.4" from "host.example.com".
Responses can contain large data sometimes.
Better patch affected systems

(Last edited by bolvan on 17 Feb 2016, 09:12)

it's really hard if not impossible to patch  "smart" connected devices...

maurer wrote:

it's really hard if not impossible to patch  "smart" connected devices...

Then i'd limit it only for those devices, not for ALL.

If you have an OpenWrt router, can't you just let the router announce itself as DNS server (which it should do by default) and then block your client from connecting to external DNS servers (UDP port 53) completely? Then you should be good to go even on IOT devices that you can't update (if they use glibc at all).

In order to protect hosts in your LAN you can apply the following changes to your OpenWrt system:

1) Limit DNS packets to 1024 bytes

uci set dhcp.@dnsmasq[0].ednspacket_max=1024
uci commit dhcp
/etc/init.d/dnsmasq restart

2) Force all LAN DNS traffic through local dnsmasq

uci add firewall redirect
uci set firewall.@redirect[-1].name="Divert DNS"
uci set firewall.@redirect[-1].proto="udp tcp"
uci set firewall.@redirect[-1].src=lan
uci set firewall.@redirect[-1].src_dport=53
uci set firewall.@redirect[-1].target=DNAT
uci commit firewall
/etc/init.d/firewall restart
jow wrote:

In order to protect hosts in your LAN you can apply the following changes to your OpenWrt system:

1) Limit DNS packets to 1024 bytes

uci set dhcp.@dnsmasq[0].ednspacket_max=1024
uci commit dhcp
/etc/init.d/dnsmasq restart

2) Force all LAN DNS traffic through local dnsmasq

uci add firewall redirect
uci set firewall.@redirect[-1].name="Divert DNS"
uci set firewall.@redirect[-1].proto="udp tcp"
uci set firewall.@redirect[-1].src=lan
uci set firewall.@redirect[-1].src_dport=53
uci set firewall.@redirect[-1].target=DNAT
uci commit firewall
/etc/init.d/firewall restart

No disrepect intended but doesn't this fix only part of the problem?  See link:

https://www.sourceware.org/ml/libc-alph … 00416.html

- Mitigating factors for UDP include:
  - A firewall that drops UDP DNS packets > 512 bytes.
  - A local resolver (that drops non-compliant responses).
  - Avoid dual A and AAAA queries (avoids buffer management error) e.g.
    Do not use AF_UNSPEC.
  - No use of `options edns0` in /etc/resolv.conf since EDNS0 allows
    responses larger than 512 bytes and can lead to valid DNS responses
    that overflow.
  - No use of `RES_USE_EDNS0` or `RES_USE_DNSSEC` since they can both
    lead to valid large EDNS0-based DNS responses that can overflow.

- Mitigating factors for TCP include:
  - Limit all replies to 1024 bytes.

At the bottom of the linked page is the patch that appears to be now in the glibc development branch as the fix.  I'm guessing this should require a patch in toolchain and a complete rebuild, which I'm probably going to pursue tonight.

It looks like trunk should be OK if you clean the toolchain and rebuild.  It should be built with 2.21 or higher as far as I can tell, and that's already patched.

CC looks to me like it's still pulling 2.19, which isn't patched at the source (yet).  So one will either need to update to 2.21 or apply patches manually.

InkblotAdmirer wrote:

It looks like trunk should be OK if you clean the toolchain and rebuild.  It should be built with 2.21 or higher as far as I can tell, and that's already patched.

CC looks to me like it's still pulling 2.19, which isn't patched at the source (yet).  So one will either need to update to 2.21 or apply patches manually.

Hi there, I have CC on my router...could you explain exeactly what I must do to mitigate this bug?

wayne1958 wrote:

Hi there, I have CC on my router...could you explain exeactly what I must do to mitigate this bug?

It looks to me like this might not be an issue unless you explicitly selected glibc from make menuconfig, and built.

I don't see how to enable the 2.21 library in CC (ignorance -- it's referenced in toolchain config files), so if you selected glibc it will likely be pulling from 2.19 which (last I checked) hasn't been patched.

In other words, I don't think you need to worry about it.  By default uClibc is used.

From memory I thought some packages were using glibc but it appears I'm mistaken.  I don't even see glibc source pulled into my toolchain directory.

Any more experienced developers care to chime in?

Some packages use "Glib" (GNOME-Lib, a GTK+ spinoff) but thats a completely different thing compared to "Glibc" (GNU C-Library, the C runtime).

InkblotAdmirer wrote:
wayne1958 wrote:

Hi there, I have CC on my router...could you explain exeactly what I must do to mitigate this bug?

It looks to me like this might not be an issue unless you explicitly selected glibc from make menuconfig, and built.

I don't see how to enable the 2.21 library in CC (ignorance -- it's referenced in toolchain config files), so if you selected glibc it will likely be pulling from 2.19 which (last I checked) hasn't been patched.

In other words, I don't think you need to worry about it.  By default uClibc is used.

From memory I thought some packages were using glibc but it appears I'm mistaken.  I don't even see glibc source pulled into my toolchain directory.

Any more experienced developers care to chime in?

many thanks, I just checked in LuCi (should have thought to do that first!) and glibc doesn't appear as installed or even available, so seems like there is no problem here...

I'm quoting from the arstechnica article
http://arstechnica.com/security/2016/02 … ulnerable/
(Similar list)

"The vulnerability relies on an oversized (2048+ bytes) UDP or TCP response, which is followed by another response that will overwrite the stack. Our suggested mitigation is to limit the response (i.e., via DNSMasq or similar programs) sizes accepted by the DNS resolver locally as well as to ensure that DNS queries are sent only to DNS servers which limit the response size for UDP responses with the truncation bit set.
    Mitigating factors for UDP include:
    - A firewall that drops UDP DNS packets > 512 bytes.
...
    Mitigating factors for TCP include:
    - Limit all replies to 1024 bytes."

Is there a disadvantage in using the 512-byte limit for UDP ?

"Bolvan> Responses can contain large data sometimes."

I can't patch a particular system quickly, so I may have to break my DNS slightly as an interim measure.

How would the TCP mitigation be implemented ? And is it required ?

Please do not limit the size of DNS responses. This was a foolish and irresponsible thing for Red Hat to have recommended for several reasons, the most important of which is that it does not actually protect your systems. The bug relies on being able to force a retry of the DNS request in order to force the heap/stack switch that leads to the buffer overflow. In other words, it's not just one packet, so limiting single packets doesn't help. Further, the exploit works just as well over TCP, so limiting the sizes of UDP packets is worse than useless.

From a protocol standpoint it's been true for 15 years that DNS answers can be, and nowadays often are, larger than 512 bytes, even on UDP. "New" technologies like EDNS0, DNSSEC, and IPv6 mean that answers will often contain more information than was asked for, even if you're not actively making use of DNSSEC/IPv6/etc. on your network. Just one common example, the query to list the root name servers (which includes the IPv4 and IPv6 addresses of all the servers in the ADDITIONAL section) is 755 bytes.

So definitely patch your systems for which patches are available, and if you have other devices you are concerned about that aren't getting updates contact the vendor(s) and demand that they provide one. This is a serious vulnerability, and I don't want to minimize that. But please don't make the problem worse by breaking your DNS in the process.

No update yet, last release was in 2017.

The discussion might have continued from here.