On Tue, May 29, 2018 at 08:30:41PM +0100, Michael Tremer (michael.tremer@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@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.