public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
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

  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