Bugzilla – Bug 547
SECURITY/DOS: unbound destroys its root.key trust anchor file when the file system runs out of space
Last modified: 2014-01-21 11:15:08 CET
This is SECURITY relevant on the local system because depending on exact configuration anyone who can write to the same filesystem as unbound can make unbound lose its data and become unable to start/operate properly.
My unbound configuration, which includes auto-trust-anchor-file, is shown below.
ISSUE 1. After the / partition had filled up, which contains my /etc/unbound directory, and after unbound rewrote its root.key file, I found the root.key file empty (0 bytes).
ISSUE 2. I found no information in the log about unbound having trouble to write that file, only info: logging.
Whether this was due to the disk full condition, or because unbound did not notice or report the trouble, remains to be reproduced and investigated in an experiment with off-system logging.
Detailed logging from startup trouble next time the computer got rebooted:
Jan 21 09:32:18 apollo unbound-anchor: /var/lib/unbound/root.key has content
Jan 21 09:32:18 apollo unbound-anchor: success: the anchor is ok
Jan 21 09:32:18 apollo unbound: [6246:0] notice: init module 0: validator
Jan 21 09:32:18 apollo unbound: [6246:0] error: failed to read /etc/unbound/root.key
Jan 21 09:32:18 apollo unbound: [6246:0] error: error reading auto-trust-anchor-file: /etc/unbound/root.key
Jan 21 09:32:18 apollo unbound: [6246:0] error: validator: error in trustanchors config
Jan 21 09:32:18 apollo unbound: [6246:0] error: validator: could not apply configuration settings.
Jan 21 09:32:18 apollo unbound: [6246:0] error: module init for module validator failed
Jan 21 09:32:18 apollo unbound: [6246:0] fatal error: failed to setup modules
Please make sure that unbound *never* overwrites configuration files directly, but always instead writes a temporary file with proper mode (use mkstemp(), other functions are racey), writes its stuff into that, closes it, all with proper error checking and reporting, and only on success rename()s the file into place. This makes sure that there is always a valid configuration (even if only an old one in ENOSPC situations).
access-control: 0.0.0.0/0 refuse
access-control: 127.0.0.0/8 allow
access-control: 192.168.0.0/16 allow
access-control: ::0/0 refuse
access-control: ::1 allow
access-control: ::ffff:127.0.0.1 allow
I also have an included file (not shown above due to copy&paste error) that contains several dozen of these line pairs:
local-zone: "yieldmanager.net" redirect
local-data: "yieldmanager.net A 127.0.0.1"
I believe this is irrelevant to the issue.
(yes the included file is irrelevant).
There is a fix for this in 1.4.16.
But the fix must be insufficient. I think it may be because the return value of fclose() was not checked (but all the fprintfs() were checked). I have added a check for the result of fclose().
After succesful write it renamed root.key.<pid>.<thread> to root.key (this is already in 1.4.16). The new code is in svn trunk of unbound (for the upcoming release).
Thank you for the bugreport! I think this fixes the issue, if not reopen or make a new one.