From: Tapani Tarvainen <ipfire@tapanitarvainen.fi>
To: development@lists.ipfire.org
Subject: Re: unbound startup
Date: Sat, 02 Jun 2018 16:02:20 +0300 [thread overview]
Message-ID: <20180602130220.GA15444@tarvainen.info> (raw)
In-Reply-To: <252b0cbfb154ce2b5d8ff185833a60252f01cb7f.camel@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 1980 bytes --]
On Tue, May 29, 2018 at 08:30:41PM +0100, Michael Tremer (michael.tremer(a)ipfire.org) wrote:
> 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.
[...]
> Your application should not rely on getting a response from the DNS servers.
Of course not. But not getting a response is different than getting
*wrong* response. And that's what's happening here.
Someone or something attempting to access intranet server could be
directed to an external one instead. I consider that a security issue.
Some sample scenarios:
Assume company X has website www.example.com and their intranet with
same name but different IP at www.example.com/intra/ (not uncommon setup).
If aomeone breaks in the external server they could exploit this bug to
break inside the firewall, e.g., by faking intranet login page they could
collect passwords.
Anybody able to hijack or spoof the external DNS servers could of
course do similar attack also with differently named intranet hosts
(intra.example.com could go to an external machine ran by blackhats).
In email setup with some addresses in @example.com being handled
differently inside the firewall could lead to sensitive messages being
delivered to wrong recipient. E.g., boss(a)example.com only existing
internally and external mail server having wildcard *@example.com
going to some spam filtering company.
That last one does not even require any actual malicious attack.
I don't think it's a catastrophic or even very bad bug, unlikely to be
exploitable in what's probably typical IPFire usage scenario, but it
is a security issue nonetheless.
Unfortunately due to travels I won't be able to do more about this for
a couple of weeks, but I'll leave a box running the quick fix I put
in bugzilla and absent any problems may submit it as a patch later,
or perhaps write a cleaner fix.
--
Tapani Tarvainen
next prev parent reply other threads:[~2018-06-02 13:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-28 6:17 Tapani Tarvainen
2018-05-29 11:57 ` Tapani Tarvainen
2018-05-29 16:05 ` Tapani Tarvainen
2018-05-29 19:30 ` Michael Tremer
2018-06-02 13:02 ` Tapani Tarvainen [this message]
2018-05-29 19:28 ` Michael Tremer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180602130220.GA15444@tarvainen.info \
--to=ipfire@tapanitarvainen.fi \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox