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