Nmap's use of gethostbyname in light of CVE-2015-0235 (GHOST)

[Daniel Miller <bonsaiviking () gmail com>]

Prompted by disclosure of CVE-2015-0235 a.k.a. "GHOST", I checked Nmap's
source for use of this function, which occurs in the following places:

1. In `nbase/getaddrinfo.c` as part of a compatibility hack when
`getaddrinfo` is not present. This use is preceded by a call to `inet_aton`
and an early return, so it is not vulnerable.

2. In `nmap.cc` as part of the validation of options to the `-b` (FTP
bounce scan) option. This one is also protected by a check on the return of
`inet_aton`. Additionally, this functionality is slated to be removed once
NSE-based port scanning is implemented (or some other suitable replacement).

3. In `libdnet-stripped/src/addr.c` in the `addr_pton` function. This *may*
be protected because a call to `ip_pton` before the `gethostbyname` call
*may* intercept the malformed address, since it has to be somewhat valid as
an IP address in order to trigger the bug. However, I have not exhausted
the possibilities of input into this function. Fortunately, the only calls
to the `addr_pton` function (#define'd to `addr_aton` in dnet/addr.h) are
within functions in libdnet itself which are either not called from our
code or are called on IPv6 addresses only (unexploitable).

4. In `nsock/examples/nsock_telnet.c`, where it is safely preceded by a
call to `inet_aton`

5. In `libpcap/nametoaddr.c` in the `pcap_nametoaddr` function. This is
only called in two places, both within the `gen_scode` function in
`libpcap/gencode.c`, and only when the INET6 macro is not defined. This is
as far as I can trace it, since libpcap internals are dark magic to me, but
at least anyone with IPv6 support should not be affected.

6. In `nping/common_modified.cc`, where it is safely preceded by a call to
`inet_aton`

7. In `nping/utils_net.cc` in the `gethostbynameCached` function, which is
not actually called anywhere. The one call to this function is commented
out in favor of a direct call to `gethostbyname`, which is number 6 above.
However, this is still a dangerous function if it were ever to be used,
since it would require the caller to remember to first call `inet_aton` to
avoid triggering the bug.

To summarize: Nmap users are probably safe; the only possible path to
exploitation would be somewhere in libpcap, but only if IPv6 support were
disabled.

On the other hand, perhaps we should be more proactive about changing these
few remaining instances over to getaddrinfo? After all, we already have a
compatibility wrapper in nbase which safely falls back to gethostbyname for
very old systems.

Dan

_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/