Flags default uses google's DNS

[Joshua Harlow]

For some reason if the following is not overriden by a setting nova will attempt to connect to google's DNS servers.

Odd code @

    cfg.StrOpt('my_ip',
               default=_get_my_ip(),
               help='host ip address'),

Of file nova/flags.py

Where that function _get_my_ip() which may be called even if the option exists as a setting (its a default??).

The function does the following:

def _get_my_ip():
    """Returns the actual ip of the local machine."""
    try:
        csock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
        csock.connect(('8.8.8.8', 80))
        (addr, port) = csock.getsockname()
        csock.close()
        return addr
    except socket.error as ex:
        return "127.0.0.1"

This seems to attempt to open a socket to google's DNS servers @ http://code.google.com/speed/public-dns/docs/using.html

 The Google Public DNS IP addresses (IPv4) are as follows:
 8.8.8.8
 8.8.4.4

Is this the correct and desired effect? I would hope not, since I doubt companies want to expose that they are using openstack to google....

[Robert Clark (robert-clark)]

So the functionality doesn't quite match the function name.

It's clearly reaching out to the internet to see if it's possible with the current configuration, if it is possible it then returns the address information of the socket. If it can't then it returns the loopback.

So I see two things wrong here:
* A call out to a third part that you might not want to have any communication with
* This code doesn't work anyway. Google's DNS servers don't appear have port 80 open

I don't see any reason to keep this quiet:
* No vulnerability in OpenStack
* Scope for a _tiny_ information leak if the code actually worked

[Robert Clark (robert-clark)]

@joshua - Thanks for submitting the report.
@vish - I've assigned this to you as your down as lead for the Nova Security Hardening team.

Might be worth a little discussion.

[Robert Clark (robert-clark)]

Dropped the privacy flag.

[Joshua Harlow (harlowja)]

So just a simple test shows that something does happen with this code even if google isn't opening port 80.

Just try this in some version of python.

>>> import socket
>>> csock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
>>> csock.connect(('8.8.8.8', 80))
>>> (addr, port) = csock.getsockname()
>>> csock.close()
>>> addr
'192.168.0.198'
>>> port
53610

[Joshua Harlow (harlowja)]

So a little investigation with wireshark, that connection is being done with UDP (the SOCK_DGRAM part) so if it was switched to TCP (socket.SOCK_STREAM) then you would see the failure u would expect there (it would also hang for a while as the socket can't be opened) as google doesn't have port 80 open (which is something that shouldn't be relied upon, who knows one day they might have a little web page there or something). Relying on this is sort of questionable, since the socket is definitely opened, no data is sent (which might be ok) but this whole part of code just has a really weird questionable security "smell to it".

Here is the TCP version which will hang.

>>> import socket
>>> csock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> csock.connect(('8.8.8.8', 80))

(wait and wait and wait for the timeout...)

[Joshua Harlow (harlowja)]

Just some useful fyi, if this was using TCP then hopefully this would receive a higher priority (even if googles isn't responding on port 80).

A nice diagram of the TCP connect cycle is @ http://www.sdsusa.com/connections/

So thanks to this being UDP it might be a little more "safe". But its still odd that googles DNS servers are being used anywhere in openstack code. :-(

[Russell Bryant (russellb)]

The code is a little bit misleading, but I have seen this pattern used elsewhere. No traffic is actually sent here at all since it's a UDP socket. The connect() call is necessary so that the IP stack will choose a source IP address. Then, getsockname() will work. This code is basically "If I were to send traffic to something out on the Internet, what source IP address would I be using". I don't really know a better way to accomplish it.

I don't consider this is a bug. Thanks for bringing up the possible concern, though.

[Joshua Harlow (harlowja)]

Misleading code isn't a bug??? A little bit sad about that. Especially since code that lists google's IP address is just waiting to be re-stated (or re-opened) as a bug. Possible more code comments, or using http://pypi.python.org/pypi/netifaces?? Thanks for at least looking at it, hopefully it can be cleaned up by essex.

[Russell Bryant (russellb)]

It doesn't look like netifaces would work to get the same information. It can provide a list of addresses, but can't tell you which one would be used as the source if you were to send traffic somehwere.

I can add a comment to the code to make it more clear what it does.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/4060

[Joshua Harlow (harlowja)]

Do u know how the operating system is determining which one can be used as the source? Since I could see the operating system having the same problem. If netifaces returns "many" that could be used as the source (which seems possibly if u have multiple NICs) it seems like the operating system would have the same problem.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/4060
Committed: http://github.com/openstack/nova/commit/e023c28a81a2b43786d60dacf9d324537ee2dfd0
Submitter: Jenkins
Branch: master

commit e023c28a81a2b43786d60dacf9d324537ee2dfd0
Author: Russell Bryant <email address hidden>
Date: Sun Feb 12 13:18:49 2012 -0500

    Add some more comments to _get_my_ip().

    bug 930513.

    This patch adds some additional comments to _get_my_ip() to try to make
    the code a bit more clear and to clarify that no traffic is actually
    sent out by this code.

    Change-Id: I6f8d4a0a51596e5c531da53f3c79c5bffca59b39