Bug 812394
| Summary: | glibc: getaddrinfo NXDOMAIN hijack for hosts with two-component hostnames | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Vincent Danen <vdanen> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | unspecified | CC: | fweimer, jakub, law, mfranc, psimerda, schwab, spoyarek |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-08-21 23:25:40 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 851521, 851671 | ||
| Bug Blocks: | 812396, 880347 | ||
*** Bug 849106 has been marked as a duplicate of this bug. *** Simply counting labels will not work as a fix because that would treat example.co.uk as a full host name. What constitutes an "effective TLD" or "public suffix" is really complicated, see http://publicsuffix.org/ . Statement: Red Hat Product Security has rated this issue as having Low security impact. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/. |
A flaw in the default behaviour of glibc's getaddrinfo() results in a way to hijack failed NXDOMAIN domain lookups has been reported [1],[2]. If the local domain name has only two components (e.g. "foo.com" rather than "host.foo.com"), due to how resolution is performed, a failed lookup of "bar.com" will be retried as "bar.com.com", as noted in resolv.conf(5): domain Local domain name. Most queries for names within this domain can use short names relative to the local domain. If no domain entry is present, the domain is determined from the local hostname returned by gethostname(2); the domain part is taken to be everything after the first '.'. Finally, if the hostname does not contain a domain part, the root domain is assumed. This is being used by the owners of the com.com domain by using a wildcard A record for "*.com.com" which redirects to an ad-heavy site. The problem is most visible when the hostname only has two components, and the TLD is ".com", but there may be others (for instance having "foo.org" as the system's hostname and being "bar.org" failing and being looked up as "bar.org.org" (currently org.org does not capture undefined subdomains). This can be mitigated by using a local hostname in conjunction with the domain name (such as using "host123.foo.com" rather than simply "foo.com"), rather than using (essentially) a NULL hostname with the domain name. The suggested resolution is to set the default of "ndots" to 0, or to not use the default domain for searches unless it has more than a TLD (e.g. ".com"). John Nagle also has noted some good information [3] regarding RFC 1535 [4] "A Security Problem and Proposed Correction With Widely Deployed DNS Software". [1] http://serverfault.com/questions/341383/possible-nxdomain-hijacking [2] http://sourceware.org/bugzilla/show_bug.cgi?id=13935 [3] http://sourceware.org/bugzilla/show_bug.cgi?id=13935#c2 [4] http://www.ietf.org/rfc/rfc1535.txt