Date: Sat, 18 Jun 2011 18:08:58 +0200 From: "Christopher J. Ruwe" <chrruwe@googlemail.com> To: <freebsd-questions@freebsd.org> Cc: freebsd-bugs@freebsd.org, reebsd@str.komkon.org Subject: problem report bin/157732, patch included Message-ID: <20110618180858.41cda851@dijkstra>
next in thread | raw e-mail | index | archive | help
--MP_/SLl018y2N3Fkkv+K9=dGjZZ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 --MP_/SLl018y2N3Fkkv+K9=dGjZZ Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=pr-bin-157732.patch --- /usr/src/contrib/traceroute/traceroute.c 2009-09-13 13:34:33.000000000 +0200 +++ /usr/home/chris/playsrc/contrib/traceroute/traceroute.c 2011-06-17 16:11:01.095616587 +0200 @@ -1625,11 +1625,11 @@ register char **p; register u_int32_t addr, *ap; - if (strlen(hostname) > 64) { + /*if (strlen(hostname) > 64) { Fprintf(stderr, "%s: hostname \"%.32s...\" is too long\n", prog, hostname); exit(1); - } + }*/ hi = calloc(1, sizeof(*hi)); if (hi == NULL) { Fprintf(stderr, "%s: calloc %s\n", prog, strerror(errno)); --MP_/SLl018y2N3Fkkv+K9=dGjZZ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110618180858.41cda851>