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

Discussion in 'Python' started by John Nagle, Mar 31, 2012.

  1. John Nagle

    John Nagle Guest

    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
    John Nagle, Mar 31, 2012
    #1
    1. Advertising

  2. 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
    Owen Jacobson, Apr 1, 2012
    #2
    1. Advertising

  3. John Nagle

    John Nagle Guest

    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/341383/possible-nxdomain-hijacking

    John Nagle
    John Nagle, Apr 1, 2012
    #3
  4. 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.
    Thomas Rachel, Apr 1, 2012
    #4
  5. Re: [OT] getaddrinfo NXDOMAIN exploit - please test on CentOS 6 64-bit

    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
    Michael Torrie, Apr 1, 2012
    #5
  6. John Nagle

    John Nagle Guest

    Re: [OT] getaddrinfo NXDOMAIN exploit - please test on CentOS 6 64-bit

    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
    John Nagle, Apr 1, 2012
    #6
  7. John Nagle

    John Nagle Guest

    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,socket.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
    John Nagle, Apr 3, 2012
    #7
  8. John Nagle

    John Nagle Guest

    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
    John Nagle, Apr 4, 2012
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ken Cox [Microsoft MVP]

    OT: IIS SSL Web server exploit warning

    Ken Cox [Microsoft MVP], Apr 25, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    339
    Ken Cox [Microsoft MVP]
    Apr 25, 2004
  2. George

    Java exploit

    George, Jun 9, 2004, in forum: Java
    Replies:
    3
    Views:
    592
    Mickey Segal
    Jun 10, 2004
  3. Alex Hunsley
    Replies:
    2
    Views:
    289
  4. Srikrishnan Iyer

    Ruby/Tk on 64 bit Centos 4.4

    Srikrishnan Iyer, Feb 4, 2007, in forum: Ruby
    Replies:
    0
    Views:
    139
    Srikrishnan Iyer
    Feb 4, 2007
  5. Sebastian W.
    Replies:
    3
    Views:
    140
    Jens Wille
    Nov 25, 2008
Loading...

Share This Page