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

[yersinia spiros <metaexploit.spiros () gmail com>]

Il 28/Gen/2015 04:18 "Daniel Miller" <bonsaiviking () gmail com> ha scritto:
> 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.

IMHO, drepper sometime ago wrote about this.
http://www.akkadia.org/drepper/userapi-ipv6.html
And so i think it is ok to have in nmap.a change like this
> Dan
>
> _______________________________________________
> Sent through the dev mailing list
> https://nmap.org/mailman/listinfo/dev
> Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/