Bug 812394 - glibc: getaddrinfo NXDOMAIN hijack for hosts with two-component hostnames
glibc: getaddrinfo NXDOMAIN hijack for hosts with two-component hostnames
Status: CLOSED WONTFIX
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20111215,reported=2...
: Security
: 849106 (view as bug list)
Depends On: 851671 851521
Blocks: 880347 812396
  Show dependency treegraph
 
Reported: 2012-04-13 11:26 EDT by Vincent Danen
Modified: 2016-11-08 11:28 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-08-21 19:25:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vincent Danen 2012-04-13 11:26:47 EDT
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
Comment 2 Florian Weimer 2012-08-17 07:39:43 EDT
*** Bug 849106 has been marked as a duplicate of this bug. ***
Comment 3 Florian Weimer 2012-08-17 07:42:18 EDT
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/ .
Comment 6 Vincent Danen 2015-08-21 19:25:24 EDT
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/.

Note You need to log in before you can comment on or make changes to this bug.