Bug 547 - SECURITY/DOS: unbound destroys its root.key trust anchor file when the file system runs out of space
SECURITY/DOS: unbound destroys its root.key trust anchor file when the file s...
Status: RESOLVED FIXED
Product: unbound
Classification: Unclassified
Component: server
1.4.16
Other Linux
: P5 blocker
Assigned To: unbound team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-01-21 10:53 CET by Matthias Andree
Modified: 2014-01-21 11:15 CET (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Andree 2014-01-21 10:53:52 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


FIX SUGGESTION:

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).


Configuration:

server:
	verbosity: 1
	statistics-interval: 3600
	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
	hide-identity: yes
	hide-version: yes
	harden-glue: yes
	private-address: 10.0.0.0/8
	private-address: 172.16.0.0/12
	private-address: 192.168.0.0/16
	private-address: 169.254.0.0/16
	private-address: fd00::/8
	private-address: fe80::/10
	private-domain: "private.not.shown.example"
	do-not-query-localhost: yes
	auto-trust-anchor-file: "/etc/unbound/root.key"
	val-log-level: 2
Comment 1 Matthias Andree 2014-01-21 10:55:32 CET
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.
Comment 2 Wouter Wijngaards 2014-01-21 11:15:08 CET
Hi Matthias,

(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.

Best regards,
   Wouter