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 <[email protected]> or
FreeBSD Security Team <[email protected]>
Good luck!
Igor
On Sat, 18 Jun 2011, Christopher J. Ruwe wrote:
Currently, I have issues mailing to *@freebsd.org, so please reply to
[email protected].
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
<[email protected]> 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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "[email protected]"
