From owner-freebsd-questions@FreeBSD.ORG Sat Jun 18 19:05:09 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32EBB106564A; Sat, 18 Jun 2011 19:05:09 +0000 (UTC) (envelope-from freebsd@str.komkon.org) Received: from eastrmfepo203.cox.net (eastrmfepo203.cox.net [68.230.241.218]) by mx1.freebsd.org (Postfix) with ESMTP id B17EB8FC20; Sat, 18 Jun 2011 19:05:08 +0000 (UTC) Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmfepo203.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20110618184602.EXJW32702.eastrmfepo203.cox.net@eastrmimpo02.cox.net>; Sat, 18 Jun 2011 14:46:02 -0400 Received: from trantor.komkon.org ([184.180.40.182]) by eastrmimpo02.cox.net with bizsmtp id xWm21g0073voiWG02Wm2Ub; Sat, 18 Jun 2011 14:46:02 -0400 X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020202.4DFCF26A.00F8,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=1.1 cv=yFHAE0zmTawA24Oq7y6/6YtGf/lGoQYA0C3uw5xHDzk= c=1 sm=1 a=ZxN8qah7hV8A:10 a=0UdTyTsmJe8A:10 a=wPDyFdB5xvgA:10 a=kj9zAlcOel0A:10 a=4a1Q6ix95ox50xXmSdffJw==:17 a=48vgC7mUAAAA:8 a=yMhMjlubAAAA:8 a=6I5d2MoRAAAA:8 a=rjblerAVAAAA:8 a=NpXsELOKAAAA:8 a=YJO-shuzAAAA:8 a=RzSn9KaDAAAA:8 a=avS908cNAAAA:8 a=A4hdxQ0fAAAA:8 a=u3rEeLJIgVKEwz1rVzMA:9 a=4acQFM0-pWcxwoTaTuUA:7 a=CjuIK1q_8ugA:10 a=TGj1aavkVc4A:10 a=SV7veod9ZcQA:10 a=751keLzJpNAA:10 a=q_IguD5MTHfKHUCY:21 a=g6zOhocHIxsa0UL5:21 a=4a1Q6ix95ox50xXmSdffJw==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Received: from trantor.komkon.org (str@localhost.komkon.org [127.0.0.1]) by trantor.komkon.org (8.14.3/8.13.3) with ESMTP id p5IIjwO6066544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 18 Jun 2011 14:45:58 -0400 (EDT) (envelope-from freebsd@str.komkon.org) Received: from localhost (str@localhost) by trantor.komkon.org (8.14.3/8.13.3/Submit) with ESMTP id p5IIjp3S066541; Sat, 18 Jun 2011 14:45:52 -0400 (EDT) (envelope-from freebsd@str.komkon.org) X-Authentication-Warning: trantor.komkon.org: str owned process doing -bs Date: Sat, 18 Jun 2011 14:45:51 -0400 (EDT) From: Igor X-X-Sender: str@trantor.komkon.org To: "Christopher J. Ruwe" In-Reply-To: <20110618180858.41cda851@dijkstra> Message-ID: References: <20110618180858.41cda851@dijkstra> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Spam-Status: No, score=-1.8 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_RP_MATCHES_RCVD,URI_HEX autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on trantor.komkon.org Cc: freebsd-bugs@freebsd.org, freebsd-questions@freebsd.org Subject: Re: problem report bin/157732, patch included X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 19:05:09 -0000 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 or FreeBSD Security Team 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 > 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