From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: unbound startup Date: Tue, 29 May 2018 20:30:41 +0100 Message-ID: <252b0cbfb154ce2b5d8ff185833a60252f01cb7f.camel@ipfire.org> In-Reply-To: <20180529115710.GB22462@tehanu.it.jyu.fi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5863976924646244087==" List-Id: --===============5863976924646244087== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, 2018-05-29 at 14:57 +0300, Tapani Tarvainen wrote: > With a bit closer look it seems this is more serious than I thought: > it's not only a bug but a security bug. I do not consider this a security issue. This might be an information leak though and cause some unintended behaviour, but that is about it. > Under certain circumstances restarting unbound (which as noted happens > with every Edit Hosts &c) can lead to loss of data as well as result > in data leaks outside the firewall. >=20 > As it is now, at unbound startup there's a time window when it gives > wrong answers to DNS queries. NXDOMAIN is bad enough and can lead to > data loss in several circumstances, but as it starts forwarders before > populating local hosts it can also return wrong answers in split DNS > situations, that is, return external IP when it should return the > internal one. This is obviously bad if exernal DNS server is > compromised or spoofed, but even when it isn't, connections intended > to intranet machines could go outside when they shouldn't. Your application should not rely on getting a response from the DNS servers. = And if there is any important data to be sent to somewhere else it should try aga= in. > Exploiting this deliberately is not all that simple and all really bad > cases I can think of require split DNS setup and knowledge or ability > to guess when unbound is restarted, but some attacks could be set up > to wait for it. >=20 > If this list is not the right place for discussing about bugs, please > redirect wherever appropriate. This is the right place. It's the dev list. -Michael --===============5863976924646244087==--