problem report bin/157732, patch included

Sat Jun 18 19:05:09 UTC 2011

1. I don't think that the proposed patch by itself would be reasonable.
Some limit should be imposed.

According to the RFC-1123 (2.1) (circa October 1989),
"Host software MUST handle host names of up to 63 characters and
       SHOULD handle host names of up to 255 characters."
http://www.ietf.org/rfc/rfc1123.txt

I am not sure if any subsequent RFC changed that.

In some discussions on the net, I've seen people mentioning that
any "component" (between the dots) of the host name should not exceed
63  characters. Upon a very quck search, I could find only 
one somewhat reliable source that supporting that:
http://support.microsoft.com/?kbid=909264&SD=tech
The maximum length of the host name and of the fully qualified domain name 
(FQDN) is 63 octets per label and 255 bytes per FQDN. This maximum 
includes 254 bytes for the FQDN and one byte for the ending dot.

I would assume that the length checks corresponding to these rules should 
be implemented.

Since more recent RFCs allowed non-ascii hostnames, that factor should be 
taken into account as well. See, e.g. here, for the discussion of that: 
http://support.microsoft.com/kb/245809

2. You are probably right in checking to make sure that bumping
up that limit of the hostname length would not result in a buffer
overflow somewhere downstream.
You should probably check that inet_addr() and all other relevant 
functions define the variables of the type and length that can handle this 
longer input.

I noticed that some Linux (2.6.26-2-686) I had access to, was capable of
handling that long host name. So, you might want to pick at how it is 
handled by Linux. (Unless that might create some sort of 
copyright/license issues.)

3. In either case, I would assume that this number should not be hardcoded 
in the function, but instead defined in one of the header files (and 
properly documented) (e.g. HostNameMaxLength).

4. Yet another thought is that some folks involved into the "TrustedBSD" 
project may have very good expertise on this or related issues.
Consider searching the source tree in TrustedBSD, in case something 
appears there that was not brought back to FreeBSD. You might also want to 
shoot a message with a question to Robert Watson <rwatson at FreeBSD.org> or 
FreeBSD Security Team <secteam at FreeBSD.org>

Good luck!

Igor

On Sat, 18 Jun 2011, Christopher J. Ruwe wrote:

> Currently, I have issues mailing to *@freebsd.org, so please reply to
> cjr at cruwe.de.
>
> I have started looking at FreeBSD bug reports recently to improve my
> skills in C, to learn more about operating systems which I am
> concentrating on at university and, at some point, contribute should my
> abilities permit (tired of being consumer of other's work only).
> I am not entirely sure I am addressing the right list, setting my issue
> on the right track will be much appreciated, ;-)
>
> I have analysed http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/157732
> as an excercise and found a hard string limit to be encoded into
> traceroute.c, checking whether the hostname passed to traceroute is
> longer than 64 (traceroute line 1621, cf.
> http://fxr.aydogan.net/xref/src/contrib/traceroute/traceroute.c#1621).
> The same code can be found in NetBSD and probably some more programs,
> as traceroute appears to be rather old code (Tue Dec 20 03:50:13 PST
> 1988 according to comment).
>
> Reading futher, I noticed, that inet_addr() was used to get IP from the
> hostname. I have not found any resources hinting that inet_addr() was
> not able to deal with hostnames longer than 64. although there is a
> report of a tracesroute (similar?) that could produce buffer overflows
> with long hostnames.
>
> Experimentally, I have removed the offending lines, compiled a world
> and ran the new traceroute with the example Igor
> <freebsd at str.komkon.org> provided, i.e.,
>
> ./playworld/usr/sbin/traceroute
> hlfxns0188w-099192079201.pppoe-dynamic.high-speed.ns.bellaliant.net
> traceroute to
> hlfxns0188w-099192079201.pppoe-dynamic.high-speed.ns.bellaliant.net
> (99.192.79.201), 64 hops max, 52 byte packets
> 1  speedport.ip (192.168.2.1)  0.419 ms  0.442 ms  0.442 ms
> 2  217.0.118.104 (217.0.118.104)  37.232 ms  37.396 ms  36.645 ms
> 3  87.186.244.186 (87.186.244.186)  38.319 ms  38.672 ms  37.741 ms
> 4 d-ec1-i.D.DE.NET.DTAG.DE (62.154.43.134)  38.376 ms 217.239.37.150
> (217.239.37.150)  38.495 ms d-ec1-i.d.de.net.dtag.de (62.154.43.134)
> 38.839 ms
> 5  194.25.211.130 (194.25.211.130)  56.736 ms  38.338 ms 38.484 ms
> 6  xe-8-1-0.was10.ip4.tinet.net (89.149.183.154)  134.724 ms
> xe-7-1-0.was10.ip4.tinet.net (89.149.183.150)  132.715 ms  133.687 ms
> 7  bell-aliant-regional-communications-gw.ip4.tinet.net
> (77.67.71.210)  131.050 ms  130.681 ms  129.450 ms
> 8 xe-5-1-0.cr02.hlfx.ns.aliant.net (207.231.227.5)  149.687 ms  150.815
> ms xe-5-0-1.cr02.hlfx.ns.aliant.net (207.231.227.9)  163.629 ms
> 9 lag-2-84.88w.ba16.hlfx.ns.aliant.net (142.176.53.57)  152.538 ms
> 150.338 ms te-4-0-0-83.88w.ba16.hlfx.ns.aliant.net (142.176.53.41)
> 151.741 ms
> 10  * * *
> 11  * * *
> 12  * * *
> 13  * * *
> 14  * * *
> 15  * * *
> 16  * *^C
>
> after which, as you can see, I aborted. The hostname looks like some
> dialup line host, which may or may not be online (and according to a
> ping, isn't). It can be seen, that the function called after that
> ominous < 64 check, inet_addr(), returns what appears to be a valid ip.
>
> I can imagine several reasons for forbidding any hostnames > 64, among
> others, limited resources on machines at the time of traceroute being
> written (1988) or, more importantly, security considerations similar to
> the buffer overflow issue I found on the net. I can find no issues
> regarding hostname-lenght in inet_addr(), though.
>
> As I am new to this kind of work, I still (and will probably for some
> time) need help. Can somebody advise me on if and if, where, to conduct
> further research on the nature of the !> 64 issue and if and if, how,
> to analyse possible security considerations of that !>64 issue?
> Futhermore, should nobody have any ideas on my fix being dangerous or
> not, how can I have my fix reviewed more thoroughly (and possibly
> integrated)?
>
> Thank you for our help, have a nice weekend, cheers
> -- 
> Christopher J. Ruwe
> TZ GMT + 2
>
>
> -- 
> Christopher J. Ruwe
> TZ GMT + 2