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
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
named.conf(note the semicolon!):
If your resolvers run Unbound, add the following line to the
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 https://blog.des.no/wp-content/uploads/2016/02/unbound.conf # 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
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
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”
BIND does not want a colon in there:
Still needs correction (trailing semicolon was OK; infix colon was not).
No, it’s correct. Terminating semicolon for BIND, separating colon for Unbound.
You’re welcome, but my name is not Dag.
My apologies. How are you addressed? Smorgrav? Dag-Erling?
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.
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 ?
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).
We are running on bind98-188.8.131.52
BIND 184.108.40.206 was discontinued three years ago.