FreeBSD and CVE-2015-7547

As you have probably heard by now, a buffer overflow was recently discovered in GNU libc’s resolver code which can allow a malicious DNS server to inject code into a vulnerable client. This was announced yesterday as CVE-2015-7547. The best sources of information on the bug are currently Google’s Online Security Blog and Carlos O’Donnell’s in-depth analysis.

Naturally, people have started asking whether FreeBSD is affected. The FreeBSD Security Officer has not yet released an official statement, but in the meantime, here is a brief look at the issue as far as FreeBSD is concerned.

First of all: neither FreeBSD itself nor native FreeBSD applications are affected. While the resolver in FreeBSD’s libc and GNU libc share a common ancestry, the bug was introduced when the latter was rewritten to send A and AAAA queries in parallel rather than sequentially when the application requests both.

However, Linux applications running under emulation on a FreeBSD system use the GNU libc and are therefore vulnerable unless patched. I believe, but have not verified, that the linux_base-c6 port contains a vulnerable version of GNU libc while the older linux_base-f10 port does not. For now, it is safest to assume that they are both vulnerable.

UPDATE 2016-02-17 18:40 UTC: the linux_base-c6 port has been updated in ports-head, 2016Q1 branch to follow, no word on linux_base-f10

UPDATE 2016-02-18 00:15 UTC: the quarterly branch has been updated

The issue can be mitigated by only using resolvers you trust, and configuring them to avoid sending responses which can trigger the bug.

If you already have your own resolvers, you can configure them to avoid sending UDP responses larger than 2048 bytes. If the response does not fit in 2048 bytes, the server will send a truncated response, and the client should retry using TCP. While a similar bug exists in the code path for TCP requests, I believe that it can only be exploited by a malicious resolver, and interposing your own resolver will protect affected Linux systems and applications.

  • If your resolvers run BIND, add the following line to the options section in named.conf (note the semicolon!):

    max-udp-size 2048;
  • If your resolvers run Unbound, add the following line to the server section in unbound.conf (no semicolon!):

    max-udp-size: 2048
  • If your resolvers run something else, please consult the documentation and look for a way to restrict the size of UDP responses to 2048 bytes.

If you do not already have your own resolvers, you can set one up in a couple of minutes as follows:

# pkg install -y unbound
# fetch -o /usr/local/etc/unbound
# vi /usr/local/etc/unbound/unbound.conf
  ... fix access-control statements as mentioned in comments ...
# echo 'unbound_enable="yes"' >>/etc/rc.conf
# service unbound start

(link to the config file)

You must then edit /etc/resolv.conf on all affected systems to point to your new resolver. If you are running Linux applications under emulation, make sure that there is no /compat/linux/etc/resolv.conf, as it would override the system-wide /etc/resolv.conf.

Note that unlike FreeBSD libc, GNU libc does not automatically pick up changes to /etc/resolv.conf, so you will have to restart all affected Linux services and applications.

12 thoughts on “FreeBSD and CVE-2015-7547”

      1. Still needs correction (trailing semicolon was OK; infix colon was not).

        1. No, it’s correct. Terminating semicolon for BIND, separating colon for Unbound.

        1. The usual algorithm is to start at the beginning and stop at the first space, so Dag-Erling, or DES if you’re in a hurry or can’t pronounce Dag-Erling.

  1. root@test:/etc/namedb# named-checkconf /etc/namedb/named.conf
    /etc/namedb/named.conf:24: unknown option ‘max-udp-size’

    I am running Free BSD 6.3 and BIND Version 9.

    Am I missing anything in the syntax ?

    1. I doubt you’re running 6.3, which was discontinued six years ago. Perhaps you meant 9.3? In any case, the golden rule when asking for help with a configuration issue is to include the configuration file (or a link to pastebin).

Leave a Reply to Dag-Erling Smørgrav Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.