CVE-2019-6475

CVE-2019-6475: A flaw in mirror zone validity checking can allow zone data to be spoofed

Versions affected: BIND 9.14.0 -> 9.14.6  and 9.15.0 -> 9.15.4
Severity: Medium
Exploitable: Remotely

Upgrade to the patched release most closely related to your current version of BIND:
BIND 9.14.7
BIND 9.15.5

CVE-2019-6476

CVE-2019-6476: An error in QNAME minimization code can cause BIND to exit with an assertion failure

Versions: BIND 9.14.0 -> 9.14.6 and 9.15.0 -> 9.15.4
Severity: Medium
Exploitable: Remotely

Upgrade to the patched release most closely related to your current version of BIND:
BIND 9.14.7
BIND 9.15.5

ping: @tcely - re: bind (9.14.3-r0) in upstream alpine for docker.

It'd be awesome to have this feature, replicating the functionality of the /etc/default/bind9 file in Debian/Ubuntu distros. It would be really useful for example for adding the -4 argument to bind in IPv4 only deployments.

A way to do it would be adding $OPTIONS to the last line in /entrypoint.sh.

UPDATE from ventz (complete): Added arbitrary parameter passing to the named daemon. Everything passed "at the end" will be directly passed to named.

For Ex:

docker run -it --rm  ventz/bind SOMETHING1 SOMETHING2

Hello, Ventz
I find a bit of race condition between the generation of rndc key at build time and the expectation of "/DATA/etc/bind" to be mounted on top of /etc/bind within the container.
Either I am doing something wrong or correct me if there is an issue.

If I mount from docker-compose a "/DATA/etc/bind" on top of /etc/bind there should be a mechanism to preserve rndc or it would be overwriten/hidden with the external information.

My docker-compose is:

$ cat docker-compose.yaml
version: "3"
services:
  bind:
    image: ventz/bind
    container_name: bind
    network_mode: host
    volumes:
      - "./etc_bind:/etc/bind"
      - "./var_cache_bind:/var/cache/bind"
      - "./var_log_named:/var/log/named"
    environment:
      - "OPTIONS=-4"
    restart: unless-stopped

I modified it to use path relatives to the docker-compose file. But of course rndc is not there after populating ./etc_bind: with container/configs/ contents, and bind fails to start because it can not find rndc.

bind    | 18-Aug-2019 08:49:57.899 ----------------------------------------------------
bind    | 18-Aug-2019 08:49:57.899 BIND 9 is maintained by Internet Systems Consortium,
bind    | 18-Aug-2019 08:49:57.900 Inc. (ISC), a non-profit 501(c)(3) public-benefit
bind    | 18-Aug-2019 08:49:57.900 corporation.  Support and training for BIND 9 are
bind    | 18-Aug-2019 08:49:57.900 available at https://www.isc.org/support
bind    | 18-Aug-2019 08:49:57.900 ----------------------------------------------------
bind    | 18-Aug-2019 08:49:57.900 found 2 CPUs, using 2 worker threads
bind    | 18-Aug-2019 08:49:57.900 using 2 UDP listeners per interface
bind    | 18-Aug-2019 08:49:57.904 using up to 4096 sockets
bind    | 18-Aug-2019 08:49:57.935 loading configuration from '/etc/bind/named.conf'
bind    | 18-Aug-2019 08:49:57.936 /etc/bind/named.conf:13: open: /etc/bind/rndc.key: file not found
bind    | 18-Aug-2019 08:49:57.939 loading configuration: file not found
bind    | 18-Aug-2019 08:49:57.939 exiting (due to fatal error)

¿What am I doing wrong?
¡Thanks you!

I've commented out allow query

forwarders are set up as 8.8.8.8 and 8.8.4.4

I've managed to set up my own lookups which work:

$ host zone10.sigyl 192.168.99.102
Using domain server:
Name: 192.168.99.102
Address: 192.168.99.102#53
Aliases: 

zone10.sigyl has address 192.168.99.103

however when I try and query another name I get..

$ host google.com 192.168.99.102
Using domain server:
Name: 192.168.99.102
Address: 192.168.99.102#53
Aliases: 

Host google.com not found: 5(REFUSED)

any ideas?

many thanks

I configured the container to be a secondary authoratative dns server.
When it receives a zone refresh from the master server, the log shows the following message:

29-Apr-2019 23:09:06.703 zone XXX.YYY/IN: refresh: could not set file modification time of '/var/cache/bind/zones/XXX.YYY.zone': permission denied

These messages appear only after the container has restarted (the file permissions have been changed by 'entrypoint.sh'.
That means, if I delete all cached zone files and start the container, the messages will never appear, unless the container is restarted and 'entrypoint.sh' executed.

Despite these messages, everything seems to function properly.

Executing the following command inside of the container works as expected.
su -s /bin/sh named -c 'touch -m /var/cache/bind/zones/XXX.YYY.zone'

It changes the file's modification time.
Which means to me, there actually is no permission problem.

FYI... you probably want to know about this. Alpine 3.10 is now current, with the BIND 9.14.3-r0 package. Also, the commit from 2 days ago for #19/CVE-2019-6471 fix is listed on GitHub with a red "x" error - it doesn't show me what the error was. It didn't get automatically posted to Docker Hub.

Is there any possibility to reload the zone file and the config file without restarting the container? Comparably with service bind9 reload on Ubuntu.

I have configured bind to allow dynamic updates from my LAN, with two bound volumes /etc/bind and /var/cache/bind. When a zone update request is received, it fails with SERVFAIL.

The bind logs reveal it is failing because bind does not have permissions to create the journal file at /etc/bind/zones/db.lan.jnl:

16-Jul-2019 01:32:04.589 client @0x56143cb40b40 172.18.0.3#58468/key dynamic-zone-key: signer "dynamic-zone-key" approved
16-Jul-2019 01:32:04.589 client @0x56143cb40b40 172.18.0.3#58468/key dynamic-zone-key: updating zone 'lan/IN': deleting rrset at 'planetexpress.lan' A
16-Jul-2019 01:32:04.589 client @0x56143cb40b40 172.18.0.3#58468/key dynamic-zone-key: updating zone 'lan/IN': adding an RR at 'planetexpress.lan' A 10.0.0.4
16-Jul-2019 01:32:04.589 /etc/bind/zones/db.lan.jnl: create: permission denied
16-Jul-2019 01:32:04.589 client @0x56143cb40b40 172.18.0.3#58468/key dynamic-zone-key: updating zone 'lan/IN': error: journal open failed: unexpected error

If I run /bin/ash in the running container and use that to execute chmod 770 /etc/bind/zones the dynamic update completes successfully:

16-Jul-2019 01:55:32.427 client @0x55e993fc7960 172.18.0.2#54044/key dynamic-zone-key: signer "dynamic-zone-key" approved
16-Jul-2019 01:55:32.427 client @0x55e993fc7960 172.18.0.2#54044/key dynamic-zone-key: updating zone 'lan/IN': deleting rrset at 'planetexpress.lan' A
16-Jul-2019 01:55:32.427 client @0x55e993fc7960 172.18.0.2#54044/key dynamic-zone-key: updating zone 'lan/IN': adding an RR at 'planetexpress.lan' A 10.0.0.4

@tcely Please note:

CVE-2018-5743 and CVE-2019-6467 especially -- just released.
(CVE-2019-6468 is not relevant for alpine version)

Need for: 9.12.4 9.14.1 is now present

Hey Ventz,

I'm automating Let's Encrypt wildcard certificate generation and have found that chmoding everything to 750 conflicts with the needs for dynamic updates because bind cannot write to the zone directory a file with JNL extension.
If that's intended behaviour, should I place zone files elsewhere? I mean, I'm putting then on a volume mapping /etc/bind

As a workaround, I did this:

#chmod -R 750 /etc/bind
chmod -R 770 /etc/bind

At least, it survives a container restart.

I saw Alpine updated BIND to 9.16.6 and thought you'd want a heads-up about it. https://git.alpinelinux.org/aports/log/main/bind/APKBUILD?h=3.12-stable

i am getting error exit code 1
i am running with command: docker run --name=dns-master -it -d --dns=8.8.8.8 --dns=8.8.4.4 -p 53:53/udp -p 53:53 -v /DATA/etc/bind:/etc/bind -v /DATA/var/cache/bind:/var/cache/bind ventz/bind

logs are below.

24-Jun-2018 12:00:55.111 starting BIND 9.11.3 (Extended Support Version) <id:a375815>
,24-Jun-2018 12:00:55.111 running on Linux x86_64 4.13.0-19-generic #22-Ubuntu SMP Mon Dec 4 11:58:07 UTC 2017
,24-Jun-2018 12:00:55.111 built with '--build=x86_64-alpine-linux-musl' '--host=x86_64-alpine-linux-musl' '--prefix=/usr' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--with-openssl=/usr' '--enable-linux-caps' '--with-libxml2' '--enable-threads' '--enable-filter-aaaa' '--enable-ipv6' '--enable-shared' '--enable-static' '--with-libtool' '--with-randomdev=/dev/random' '--mandir=/usr/share/man' '--infodir=/usr/share/info' 'build_alias=x86_64-alpine-linux-musl' 'host_alias=x86_64-alpine-linux-musl' 'CC=gcc' 'CFLAGS=-Os -fomit-frame-pointer -D_GNU_SOURCE' 'LDFLAGS=-Wl,--as-needed' 'CPPFLAGS=-Os -fomit-frame-pointer'
,24-Jun-2018 12:00:55.111 running as: named -c /etc/bind/named.conf -g -u named
,24-Jun-2018 12:00:55.111 ----------------------------------------------------
,24-Jun-2018 12:00:55.111 BIND 9 is maintained by Internet Systems Consortium,
,24-Jun-2018 12:00:55.111 Inc. (ISC), a non-profit 501(c)(3) public-benefit 
,24-Jun-2018 12:00:55.111 corporation.  Support and training for BIND 9 are 
,24-Jun-2018 12:00:55.112 available at https://www.isc.org/support
,24-Jun-2018 12:00:55.113 ----------------------------------------------------
,24-Jun-2018 12:00:55.113 found 1 CPU, using 1 worker thread
,24-Jun-2018 12:00:55.113 using 1 UDP listener per interface
,24-Jun-2018 12:00:55.114 using up to 4096 sockets
,24-Jun-2018 12:00:55.158 loading configuration from '/etc/bind/named.conf'
,24-Jun-2018 12:00:55.162 open: /etc/bind/named.conf: file not found
,24-Jun-2018 12:00:55.163 loading configuration: file not found
,24-Jun-2018 12:00:55.163 exiting (due to fatal error)
,24-Jun-2018 12:01:07.418 starting BIND 9.11.3 (Extended Support Version) <id:a375815>
,24-Jun-2018 12:01:07.418 running on Linux x86_64 4.13.0-19-generic #22-Ubuntu SMP Mon Dec 4 11:58:07 UTC 2017
,24-Jun-2018 12:01:07.418 built with '--build=x86_64-alpine-linux-musl' '--host=x86_64-alpine-linux-musl' '--prefix=/usr' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--with-openssl=/usr' '--enable-linux-caps' '--with-libxml2' '--enable-threads' '--enable-filter-aaaa' '--enable-ipv6' '--enable-shared' '--enable-static' '--with-libtool' '--with-randomdev=/dev/random' '--mandir=/usr/share/man' '--infodir=/usr/share/info' 'build_alias=x86_64-alpine-linux-musl' 'host_alias=x86_64-alpine-linux-musl' 'CC=gcc' 'CFLAGS=-Os -fomit-frame-pointer -D_GNU_SOURCE' 'LDFLAGS=-Wl,--as-needed' 'CPPFLAGS=-Os -fomit-frame-pointer'
,24-Jun-2018 12:01:07.418 running as: named -c /etc/bind/named.conf -g -u named
,24-Jun-2018 12:01:07.418 ----------------------------------------------------
,24-Jun-2018 12:01:07.418 BIND 9 is maintained by Internet Systems Consortium,
,24-Jun-2018 12:01:07.418 Inc. (ISC), a non-profit 501(c)(3) public-benefit 
,24-Jun-2018 12:01:07.418 corporation.  Support and training for BIND 9 are 
,24-Jun-2018 12:01:07.418 available at https://www.isc.org/support
,24-Jun-2018 12:01:07.418 ----------------------------------------------------
,24-Jun-2018 12:01:07.418 found 1 CPU, using 1 worker thread
,24-Jun-2018 12:01:07.418 using 1 UDP listener per interface
,24-Jun-2018 12:01:07.420 using up to 4096 sockets
,24-Jun-2018 12:01:07.460 loading configuration from '/etc/bind/named.conf'
,24-Jun-2018 12:01:07.462 open: /etc/bind/named.conf: file not found
,24-Jun-2018 12:01:07.462 loading configuration: file not found
,24-Jun-2018 12:01:07.462 exiting (due to fatal error)
,

Reporting two vulnerabilities - both are High severity and exploitable Remotely

CVE-2020-8616: BIND does not sufficiently limit the number of fetches performed when processing referrals

In order for a server performing recursion to locate records in the DNS graph it must be capable of processing referrals, such as those received when it attempts to query an authoritative server for a record which is delegated elsewhere. In its original design BIND (as well as other nameservers) does not sufficiently limit the number of fetches which may be performed while processing a referral response.

A malicious actor who intentionally exploits this lack of effective limitation on the number of fetches performed when processing referrals can, through the use of specially crafted referrals, cause a recursing server to issue a very large number of fetches in an attempt to process the referral.

This has at least two potential effects:

• The performance of the recursing server can potentially be degraded by the additional work required to perform these fetches, and

• The attacker can exploit this behavior to use the recursing server as a reflector in a reflection attack with a high amplification factor.

and

CVE-2020-8617: A logic error in code which checks TSIG validity can be used to trigger an assertion failure in tsig.c

An error in BIND code which checks the validity of messages containing TSIG resource records can be exploited by an attacker to trigger an assertion failure in tsig.c, resulting in denial of service to clients.

Using a specially-crafted message, an attacker may potentially cause a BIND server to reach an inconsistent state if the attacker knows (or successfully guesses) the name of a TSIG key used by the server.

Since BIND, by default, configures a local session key even on servers whose configuration does not otherwise make use of it, almost all current BIND servers are vulnerable.

In releases of BIND dating from March 2018 and after, an assertion check in tsig.c detects this inconsistent state and deliberately exits. Prior to the introduction of the check the server would continue operating in an inconsistent state, with potentially harmful results.

@tcely ping. I think the alpine project moved to Gitlab a while back.

Versions affected: BIND 9.11.0 -> 9.11.7, 9.12.0 -> 9.12.4-P1, 9.14.0 -> 9.14.2. Also all releases of the BIND 9.13 development branch and version 9.15.0 of the BIND 9.15 development branch. BIND Supported Preview Edition versions 9.11.3-S1 -> 9.11.7-S1.

Severity: Medium

Exploitable: Remotely

Description:

A race condition which may occur when discarding malformed packets can result in BIND exiting due to a REQUIRE assertion failure in dispatch.c.

Impact:

An attacker who can cause a resolver to perform queries which will be answered by a server which responds with deliberately malformed answers can cause named to exit, denying service to clients.

Workarounds:

None.

Solution:

Upgrade to the patched release most closely related to your current version of BIND:

BIND 9.11.8
BIND 9.12.4-P2
BIND 9.14.3
BIND 9.15.1

@tcely ^ just FYI

By default, I see almost no logging.
I'd like to log queries refused, not found, and errors in general.

my docker run:

docker run \
 --name=bind9 \
 --volume="/srv/bind9/etc/bind:/etc/bind" \
 --volume="/srv/bind9/var/cache/bind:/var/cache/bind" \
 -p 53:53 -p 53:53/udp \
 --restart=unless-stopped \
 --detach=true \
 ventz/bind:9.14.7-r0

in other words, you should move the last line from entrypoint.sh to COMMAND dockerfile directive.

this will allow to launch bind with custom options but also launch other tools from the container.

instead of latest you should also keep a tag like :9.9.3_p4 for every release of your image

Hi Ventz,

A couple of questions/issues about your great docker container:

• named is launched with the "-g" option from entrypoint.sh. The unfortunate thing about that is it means logging can't be enabled, since -g redirects all logging to stdout, and causes named to ignore other logging directives. I would really like to configure logging to a volume. Any change of changing it to -f? I can't see any way to override -g (other than rebullding).

• In entrypoint.sh, you chmod -R 770 on the two volumes. That makes everything in the volumes executable, which doesn't seem write. Was it mean instead to just chmod, rather than "-R"?

thanks,
Stuart

Adding comments from @tcely:

Why not just use the installed /etc/bind/bind.keys file? Downloading like this without any sort of verification seems very unsafe.

# -chown -R named:named /var/cache/bind

This line should remain.

I don't see any reason why you should change from /var/cache/bind to /var/bind but without this chown line you're going to break working configurations that mount /etc/bind and /var/cache/bind and that should be avoided.

You should only have common options in this file and add a include "/etc/bind/named.conf.options.local"; with includes in that file for both recursion and authoritative options examples.

This allows you to remove all the common options from both files and allows for easy customization of the options by the local admin.

As per PR #1, add the ability to syslog remotely.

Currently the -g option prevents any kind of log configuration.

CVE-2019-6477: TCP-pipelined queries can bypass tcp-clients limit

Severity: Medium
Exploitable: Remotely
CVSS Score: 6.5
Versions affected: BIND 9.11.6-P1 -> 9.11.12, 9.12.4-P1 -> 9.12.4-P2, 9.14.1 -> 9.14.7, and versions 9.11.5-S6 -> 9.11.12-S1 of BIND 9 Supported Preview Edition. Versions 9.15.0 -> 9.15.5 of the BIND 9.15 development branch are also affected. Versions prior to BIND 9.11.0 have not been evaluated for vulnerability to CVE-2019-6477.

Work around:

# Disable server TCP pipelining:
keep-response-order { any; };

Solution upstream:

BIND 9.11.13
BIND 9.14.8
BIND 9.15.6

Add example configs and sample/sub zones so that users can deploy faster if they have not used bind.

alpinelinux/aports#6717

Fixes for:

#   9.12.4-r0:
#     - CVE-2019-6465
#     - CVE-2018-5745
#     - CVE-2018-5745CVE-2018-5745

CVE-2018-5745 and CVE-2018-5744 are also covered by v 9.12.3-P1

Hi, is it possible to remove the "-g" in the execution command of named? Because I would like to output the logs to files instead of the console.

File: docker-bind/container/entrypoint.sh
Run in foreground and log to STDERR (console):
exec /usr/sbin/named -c /etc/bind/named.conf -g -u named $OPTIONS

Thanks in advance.
Best.

Please also add the bind-plugins package to the container.

This package contains the filter-aaaa plugin. Starting from 9.14 this filter was split-off from the main package

Some more info on how to use the plugin: ftp://ftp.isc.org/isc/bind9/cur/9.14/doc/arm/man.filter-aaaa.html