getaddrinfo NXDOMAIN exploit - please test on CentOS 6 64-bit

[John Nagle]

Some versions of CentOS 6 seem to have a potential
getaddrinfo exploit. See

To test, try this from a command line:

ping example

If it fails, good. If it returns pings from "example.com", bad.
The getaddrinfo code is adding ".com" to the domain.

If that returns pings, please try

ping noexample.com

There is no "noexample.com" domain in DNS. This should time out.
But if you get ping replies from a CNET site, let me know.
Some implementations try "noexample.com", get a NXDOMAIN error,
and try again, adding ".com". This results in a ping of
"noexample.com,com". "com.com" is a real domain, run by a
unit of CBS, and they have their DNS set up to catch all
subdomains and divert them to, inevitably, an ad-oriented
junk search page. (You can view the junk page at
"http://slimeball.com.com". Replace "slimeball" with anything
else you like; it will still resolve.)

If you find a case where "ping noexample.com" returns a reply,
then try it in Python:


import socket
socket.getaddrinfo("noexample.com", 80)

That should return an error. If it returns the IP address of
CNET's ad server, there's trouble.

This isn't a problem with the upstream DNS. Usually, this sort
of thing means you're using some sleazy upstream DNS provider
like Comcast. That's not the case here. "host" and "nslookup"
aren't confused. Only programs that use getaddrinfo, like "ping",
"wget", and Python, have this ".com" appending thing. Incidentally,
if you try "noexample.net", there's no problem, because the
owner of "net.com" hasn't set up their DNS to exploit this.

And, of course, it has nothing to do with browser toolbars. This
is at a much lower level.

If you can make this happen, report back the CentOS version and
the library version, please.

John Nagle

 

[Owen Jacobson]

Some versions of CentOS 6 seem to have a potential
getaddrinfo exploit. See

To test, try this from a command line:

ping example

If it fails, good. If it returns pings from "example.com", bad.
The getaddrinfo code is adding ".com" to the domain.

There is insufficient information in your diagnosis to make that
conclusion. For example: what network configuration services (DHCP
clients and whatnot, along with various desktop-mode configuration
tools and services) are running? What kernel and libc versions are you
running? What are the contents of /etc/nsswitch.conf? Of
/etc/resolv.conf (particularly, the 'search' entries)? What do
/etc/hosts, LDAP, NIS+, or other hostname services say about the names
you're resolving? Does a freestanding C program that directly calls
getaddrinfo and that runs in a known-good loader environment exhibit
the same surprises? Name resolution is not so simple that you can
conclude "getaddrinfo is misbehaving" from the behaviour of ping, or of
your Python sample, alone.

In any case, this seems more appropriate for a Linux or a CentOS
newsgroup/mailing list than a Python one. Please do not reply to this
post in comp.lang.python.

-o

 

[John Nagle]

There is insufficient information in your diagnosis to make that
conclusion. For example: what network configuration services (DHCP
clients and whatnot, along with various desktop-mode configuration tools
and services) are running? What kernel and libc versions are you
running? What are the contents of /etc/nsswitch.conf? Of
/etc/resolv.conf (particularly, the 'search' entries)? What do
/etc/hosts, LDAP, NIS+, or other hostname services say about the names
you're resolving? Does a freestanding C program that directly calls
getaddrinfo and that runs in a known-good loader environment exhibit the
same surprises? Name resolution is not so simple that you can conclude
"getaddrinfo is misbehaving" from the behaviour of ping, or of your
Python sample, alone.

In any case, this seems more appropriate for a Linux or a CentOS
newsgroup/mailing list than a Python one. Please do not reply to this
post in comp.lang.python.

-o

I expected that some noob would have a reply like that.

A more detailed discussion appears here:

http://serverfault.com/questions/341383/possible-nxdomain-hijacking

John Nagle

 

[Thomas Rachel]

Am 01.04.2012 06:31 schrieb John Nagle:

I expected that some noob would have a reply like that.

You are unable to provide appropriate information, fail to notice that
the problem has nothing to do with Python AND call others a noob?

Shame on you.

 

[Michael Torrie]

If you can make this happen, report back the CentOS version and
the library version, please.

CentOS release 6.2 (Final)
glibc-2.12-1.47.el6_2.9.x86_64

example does not ping
example.com does not resolve to example.com.com

Removed all "search" and "domain" entries from /etc/resolve.conf

 

[John Nagle]

CentOS release 6.2 (Final)
glibc-2.12-1.47.el6_2.9.x86_64

example does not ping
example.com does not resolve to example.com.com

Removed all "search" and "domain" entries from /etc/resolve.conf

It's a design bug in glibc. I just submitted a bug report.

http://sourceware.org/bugzilla/show_bug.cgi?id=13935

It only appears if you have a machine with a two-component domain
name ending in ".com" as the actual machine name. Most hosting
services generate some long arbitrary name as the primary name,
but I happen to have a server set up as "companyname.com".

The default rule for looking up domains in glibc is that the
"domain" is everything after the FIRST ".". Failed lookups
are retried with that "domain" appended. The idea, back
in the 1980s, was that if you're on "foo.bigcompany.com",
and look up "bar", it's looked up as "bar.bigcompany.com".
This idea backfires when the actual hostname only
has two components, and the search just appends ".com".

There is a "com.com" domain, and this gets them traffic.
They exploit this to send you (where else) to an ad-heavy page.
Try "python.com.com", for example,and you'll get an ad for a
Java database.

The workaround in Python is to add the AI_CANONNAME flag
to getaddrinfo calls, then check that the returned domain
name matches the one put in.

Good case:[(2, 1, 6, 'python.org', ('82.94.164.162', 80)), (2, 2, 17, '',
('82.94.164.162', 80)), (2, 3, 0, '', ('82.94.164.162', 80)), (10, 1, 6,
'', ('2001:888:2000:d::a2', 80, 0, 0)), (10, 2, 17, '',
('2001:888:2000:d::a2', 80, 0, 0)), (10, 3, 0, '',
('2001:888:2000:d::a2', 80, 0, 0))]

Bad case:[(2, 1, 6, 'phx1-ss-2-lb.cnet.com', ('64.30.224.112', 80)), (2, 2, 17,
'', ('64.30.224.112', 80)), (2, 3, 0, '', ('64.30.224.112', 80))]

Note that what went in isn't what came back. getaddrinfo has
been pwned.

Again, you only get this if you're on a machine whose primary host
name is "something.com", with exactly two components ending in ".com".


John Nagle

 

[John Nagle]

It's a design bug in glibc. I just submitted a bug report.

http://sourceware.org/bugzilla/show_bug.cgi?id=13935

It only appears if you have a machine with a two-component domain
name ending in ".com" as the actual machine name. Most hosting
services generate some long arbitrary name as the primary name,
but I happen to have a server set up as "companyname.com".

The default rule for looking up domains in glibc is that the
"domain" is everything after the FIRST ".". Failed lookups
are retried with that "domain" appended. The idea, back
in the 1980s, was that if you're on "foo.bigcompany.com",
and look up "bar", it's looked up as "bar.bigcompany.com".
This idea backfires when the actual hostname only
has two components, and the search just appends ".com".

There is a "com.com" domain, and this gets them traffic.
They exploit this to send you (where else) to an ad-heavy page.
Try "python.com.com", for example,and you'll get an ad for a
Java database.

The workaround in Python is to add the AI_CANONNAME flag
to getaddrinfo calls, then check that the returned domain
name matches the one put in.

That workaround won't work for some domains. For example,
[(2, 1, 6, 'orig-10005.themarker.cotcdn.net', ('208.93.137.80', 80))]

Nor will addiing options to /etc/resolv.conf work well, because
that file is overwritten by some system administration programs.

I may have to bring in "dnspython" to get a reliable DNS lookup.

John Nagle

 

[John Nagle]

The same bug is in "dnspython". Submitted a bug report there,
too.

https://github.com/rthalley/dnspython/issues/6

John Nagle