problem report bin/157732, patch included

Christopher J. Ruwe chrruwe at googlemail.com
Sat Jun 18 16:23:38 UTC 2011


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr-bin-157732.patch
Type: text/x-patch
Size: 542 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-bugs/attachments/20110618/3f5ac11c/pr-bin-157732.bin


More information about the freebsd-bugs mailing list