From owner-freebsd-questions@FreeBSD.ORG Sun Jun 19 20:50:47 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 765451065673 for ; Sun, 19 Jun 2011 20:50:47 +0000 (UTC) (envelope-from chrruwe@googlemail.com) Received: from mail-fx0-f68.google.com (mail-fx0-f68.google.com [209.85.161.68]) by mx1.freebsd.org (Postfix) with ESMTP id EE52F8FC16 for ; Sun, 19 Jun 2011 20:50:46 +0000 (UTC) Received: by fxm15 with SMTP id 15so171799fxm.7 for ; Sun, 19 Jun 2011 13:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:date:from:to:subject:message-id:in-reply-to :references:reply-to:x-mailer:mime-version:content-type :content-transfer-encoding; bh=Fb5I0LNxU0voI46ERX3RZyLEiVtDfaY/akudJkdvwwM=; b=cPYBQfQ0Mkx4ggGFD5Y5UeDTH83xZ0j6zWomT9W1y26cI9T+iFFGmWMOhc8+3+KPi3 fNN/p7bGR5wUvfgvX4VaKddPJoJfqsa5QZl+5HbSinD6/kLMlMKzFlTKDl9x+2+9qXNN vIOrfJNtMwEIIN71RqFwRT395WU+LRc3owKLg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=xA02H1TK/LBJjSIolz7Pdker341+JQ74FJOBwslDwta+wEnmawJQ4DW3iz6M1KU0eA jLl9aFjGAwncaSS8/asANUhUMGuV0iU407ZxJnPUWc5joOLdlUEPAWRoOsjiGFCsL19r nxnm490QMvMW7HynINP+D7o0lr9pDUHo1WTys= Received: by 10.223.54.148 with SMTP id q20mr2929867fag.84.1308516645642; Sun, 19 Jun 2011 13:50:45 -0700 (PDT) Received: from dijkstra (p5B37AE3E.dip.t-dialin.net [91.55.174.62]) by mx.google.com with ESMTPS id 10sm910092faw.0.2011.06.19.13.50.43 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 19 Jun 2011 13:50:44 -0700 (PDT) Date: Sun, 19 Jun 2011 22:50:38 +0200 From: "Christopher J. Ruwe" To: freebsd-questions@freebsd.org Message-ID: <20110619225038.1dcda180@dijkstra> In-Reply-To: References: <20110618180858.41cda851@dijkstra> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; amd64-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: problem report bin/157732 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjr@cruwe.de List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 20:50:47 -0000 On Sat, 18 Jun 2011 14:45:51 -0400 (EDT) Igor wrote: >=20 >=20 > 1. I don't think that the proposed patch by itself would be > reasonable. Some limit should be imposed. >=20 > 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 >=20 > I am not sure if any subsequent RFC changed that. The wording is, interestingly, ambiguous, especially when comparing RFC1123 to earlier and later RFCs. It looks like one changed ones mind several times or was not particularly cautious with the wording: =46rom _should_ I would derive that it is _recommended_ that sw supports up to 255 characters. RFC2181 (http://tools.ietf.org/html/rfc2181#section-11) _limits_ domain names to 255 octets, which sound like 254 characters to me (adding one for the implicit terminating '.'. That is also what RFC1035 specifies (=C2=A72.3.4, http://www.ietf.org/rfc/rfc1035.txt), so that "Host software MUST handle host names of up to 63 characters and SHOULD handle host names of up to 255 characters." Thus, RFC 1123 should rather be read " ... should handle host names of _at most_ 255 octets." This is also what Tanenbaum, Computer Networks, 5th ed, is stating when discussing DNS. Interestingly, wikipedia.org claims only 253 characters, which sounds to be like a superfluous double subtraction of the terminating dot.=20 >=20 > 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 quick search, I could find only=20 > one somewhat reliable source that supporting that: > http://support.microsoft.com/?kbid=3D909264&SD=3Dtech > 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. see above > I would assume that the length checks corresponding to these rules > should be implemented. I can follow your argument up to here. What I do not understand is why anything bad should happen if you supply an argument of greater length to inet_addr(). =20 > 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 You are probably right, but that is well over my head. Superficially looking at the relevant RFCs (i.e., 3492 and 5891), there does not seem an extension of domain record length to be issued there. > 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=20 > functions define the variables of the type and length that can handle > this longer input. >=20 > 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=20 > copyright/license issues.) Looking over the fence, the Linux traceroute calls getaddr(), which does check against hostname length and also has a limit of 64. Calling traceroute with anything longer than 64 chars will result in a "traceroute: hostname "abcdefghi.abcdefghi.abcdefghi.ab..." is too long" error. Solaris, on the other hand, calls a getaddr() in getaddrinfo (http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libsocke= t/inet/getaddrinfo.c), which checks against a MAXHOSTNAMELENGTH=3D256 defined in netdb.h (http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libresol= v/netdb.h). Anyway, it performs for the example from the PR. When supplying an arbitary string longer than 255 chars, traceroute from Solaris terminates with a memory allocation error as defined in EAI_MEMORY (also defined in netdb.h).=20 TrustedBSD has the same <64 chars limit and is, I gather, not too dissimilar. As an aside, inet_addr() is, i gather, part of POSIX (http://pubs.opengroup.org/onlinepubs/009695399/functions/inet_addr.html), so I wonder, why so many do not implement inet_getaddr(), but have some home-brew called get_addr()? > 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). Such as in Solaris, ... BTW, there is a MAXHOSTNAMELEN 64 defined in traceroute.c (http://fxr.aydogan.net/xref/src/contrib/traceroute/traceroute.c#267) ... it escapes me why it isn't used. > 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 Thanks for that hint. Cheers, --=20 Christopher J. Ruwe TZ GMT + 2 --=20 Christopher J. Ruwe TZ GMT + 2