problem report bin/157732

[Christopher J. Ruwe]

On Sat, 18 Jun 2011 14:45:51 -0400 (EDT)
Igor <freebsd at str.komkon.org> wrote:

> 
> 
> 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.

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:

From _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
(§2.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. 

> 
> 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 
> 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.

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().
 
> 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 
> 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.)

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/libsocket/inet/getaddrinfo.c),
which checks against a MAXHOSTNAMELENGTH=256 defined in netdb.h
(http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libresolv/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). 

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
> <rwatson at FreeBSD.org> or FreeBSD Security Team <secteam at FreeBSD.org>

Thanks for that hint. Cheers,
-- 
Christopher J. Ruwe
TZ GMT + 2


-- 
Christopher J. Ruwe
TZ GMT + 2