Missing check for domain ownership
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Designate |
Fix Released
|
High
|
Kiall Mac Innes |
Bug Description
Designate currently does not check if a tenant asking for domain creation actually controls the domain according to the (internal or public) DNS.
This causes at least the following issues:
(a) The first-come-
(b) Registration of second-level public suffixes such “co.uk” is not blocked. If a tenant creates such domains, no one else can create subdomains under that, including legitimate domain names such as “example.co.uk“.
(c) A malicious tenant may create domains for name servers whose names are currently not managed by this Designate instance and add A records. This enables domain hijacking.
Before:
; <<>> DiG 9.9.4-RedHat-
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56445
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1680
;; QUESTION SECTION:
;example.org. IN NS
;; ANSWER SECTION:
example.org. 3600 IN NS ns1.unmanaged.
example.org. 3600 IN NS ns1.example.com.
;; Query time: 1 msec
;; SERVER: 10.35.6.
;; WHEN: Thu Jun 25 18:17:41 IDT 2015
;; MSG SIZE rcvd: 104
After the malicious tenant has created a domain “ns1.unmanaged.
; <<>> DiG 9.9.4-RedHat-
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62622
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1680
;; QUESTION SECTION:
;example.org. IN NS
;; ANSWER SECTION:
example.org. 3600 IN NS ns1.example.com.
example.org. 3600 IN NS ns1.unmanaged.
;; ADDITIONAL SECTION:
ns1.unmanaged.
;; Query time: 43 msec
;; SERVER: 10.35.6.
;; WHEN: Thu Jun 25 18:19:06 IDT 2015
;; MSG SIZE rcvd: 120
If the malicious tenant controls the IP address 192.0.2.7 and runs a suitable name server there, they can hijack the domain.
(d) It is completely unsafe to use a combined authoritative/
I believe this results in a security vulnerability (which may affect already existing production deployments), so we need to communicate this to upstream and the OpenStack security team.
Fixing this issue appears *very* difficult. (d) points towards one approach: have complete separate name servers for each tenant, on dedicated IP addresses. However, for public DNS deployments, this may not be possible due to IPv4 address space limitations.
I believe ISPs address this by tying DNS management to registry updates: A customer can maintain control of a domain in their systems only if an automated request to register the domain at the registry level succeeds in a reasonable time frame. The “co.uk” aspect is taken care of because customers can only register domains for which there is a known registry configured in the system (because the ISP needs to have negotiated access to the registry database, otherwise they would not be able to register domains on behalf of their customers).
Changed in designate: | |
status: | New → In Progress |
assignee: | nobody → Kiall Mac Innes (kiall) |
milestone: | none → liberty-2 |
importance: | Undecided → High |
information type: | Private Security → Public |
Changed in designate: | |
status: | Fix Committed → Fix Released |
Changed in designate: | |
milestone: | liberty-2 → 1.0.0 |
Downstream bug: https:/ /bugzilla. redhat. com/show_ bug.cgi? id=1235734