Date: Sat, 18 Jun 2011 14:45:51 -0400 (EDT) From: Igor <freebsd@str.komkon.org> To: "Christopher J. Ruwe" <cjr@cruwe.de> Cc: freebsd-bugs@freebsd.org, freebsd-questions@freebsd.org Subject: Re: problem report bin/157732, patch included Message-ID: <alpine.BSF.2.00.1106181358170.65936@trantor.komkon.org> In-Reply-To: <20110618180858.41cda851@dijkstra> References: <20110618180858.41cda851@dijkstra>
next in thread | previous in thread | raw e-mail | index | archive | help
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@FreeBSD.org> or
FreeBSD Security Team <secteam@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@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1106181358170.65936>