Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > getaddrinfo NXDOMAIN exploit - please test on CentOS 6 64-bit

Reply
Thread Tools

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

 
 
John Nagle
Guest
Posts: n/a
 
      03-31-2012
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
 
Reply With Quote
 
 
 
 
Owen Jacobson
Guest
Posts: n/a
 
      04-01-2012
On 2012-03-31 22:58:45 +0000, John Nagle said:

> 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

 
Reply With Quote
 
 
 
 
John Nagle
Guest
Posts: n/a
 
      04-01-2012
On 3/31/2012 9:26 PM, Owen Jacobson wrote:
> On 2012-03-31 22:58:45 +0000, John Nagle said:
>
>> 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
>

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

A more detailed discussion appears here:

http://serverfault.com/questions/341...main-hijacking

John Nagle
 
Reply With Quote
 
Thomas Rachel
Guest
Posts: n/a
 
      04-01-2012
Am 01.04.2012 06:31 schrieb John Nagle:

>> 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.


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.
 
Reply With Quote
 
Michael Torrie
Guest
Posts: n/a
 
      04-01-2012
On 03/31/2012 04:58 PM, John Nagle wrote:
> 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
 
Reply With Quote
 
John Nagle
Guest
Posts: n/a
 
      04-01-2012
On 4/1/2012 9:26 AM, Michael Torrie wrote:
> On 03/31/2012 04:58 PM, John Nagle wrote:
>> 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


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:
>>> s = "python.org"
>>> socket.getaddrinfo(s, 80, 0,0, 0, socket.AI_CANONNAME)

[(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:
>>> s = "noexample.com"
>>> socket.getaddrinfo(s, 80, 0,0, 0, socket.AI_CANONNAME)

[(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

 
Reply With Quote
 
John Nagle
Guest
Posts: n/a
 
      04-03-2012
On 4/1/2012 1:41 PM, John Nagle wrote:
> On 4/1/2012 9:26 AM, Michael Torrie wrote:
>> On 03/31/2012 04:58 PM, John Nagle wrote:


>> 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.


That workaround won't work for some domains. For example,

>>> socket.getaddrinfo(s,"http",0,0,socket.SOL_TCP,soc ket.AI_CANONNAME)

[(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
 
Reply With Quote
 
John Nagle
Guest
Posts: n/a
 
      04-04-2012
On 4/2/2012 6:53 PM, John Nagle wrote:
> On 4/1/2012 1:41 PM, John Nagle wrote:
>> On 4/1/2012 9:26 AM, Michael Torrie wrote:
>>> On 03/31/2012 04:58 PM, John Nagle wrote:

>
>>> 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


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

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

John Nagle
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
httplib and socket.getaddrinfo mirandacascade@yahoo.com Python 1 12-23-2006 08:29 AM
getaddrinfo not found on SCO OpenServer 5.0.5 edcdave@gmail.com Python 4 07-23-2006 06:23 PM
urllib2.URLError: <urlopen error (7, 'getaddrinfo failed')> when trying to connect through a proxy Matt Python 0 03-01-2005 08:07 PM
result sorting in socket.getaddrinfo? Bernhard Schmidt Python 0 10-09-2004 12:49 AM
test test test test test test test Computer Support 2 07-02-2003 06:02 PM



Advertisments