Bug 1166 - Use cname to bypass private-address/private-domain enforcement
Use cname to bypass private-address/private-domain enforcement
Status: ASSIGNED
Product: unbound
Classification: Unclassified
Component: server
1.5.10
x86_64 Linux
: P5 normal
Assigned To: unbound team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-11-30 05:00 CET by Kris Budhram
Modified: 2016-11-30 20:42 CET (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kris Budhram 2016-11-30 05:00:36 CET
Hello,

If I have unbound configured with the following options:
private-address: 10.0.0.0/8
private-domain: "privatedomain.com"

Then private-address resolution with "privatedomain.com" is enforced properly. eg, 
$ host vault.privatedomain.com
vault.privatedomain.com A 10.0.0.1

But attacker submitted lookups will bypass the DNS Rebinding protection. eg,
$ host www.baddomain.org
www.baddomain.org CNAME vault.privatedomain.com
vault.privatedomain.com A 10.0.0.1
Comment 1 Wouter Wijngaards 2016-11-30 09:30:25 CET
Hi Kbudhram,

Yes CNAMEs can change the name to another one and then bypass the localzone filter.  This is part of the design and not something I can fix for you.  Unbound first checks for the localzone filters, and once that is done it works on the internetfacing resolution.  That part then has a CNAME, but no longer has the localzone filters, so it gets the answer from the internet.

Best regards, Wouter
Comment 2 Kris Budhram 2016-11-30 20:42:18 CET
Hi Wouter,

We see the problem when the internetfacing resolution comes back, and the CNAME switches to a lookup on an internal stubzone. I understand that iter_priv methods only look at the currently handled packet, and not any of the history for the request, so the bypass succeeds.

Is it worthwhile to block resolution at the CNAME lookup, if it would resolve to a private-domain zone record? eg, 
$ host www.baddomain.org
www.baddomain.org NXDOMAIN