Date: Wed, 26 Mar 2003 14:33:06 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: David J Duchscher <daved@nostrum.com> Cc: Mark_Andrews@isc.org Subject: Re: Resolver Issues (non valid hostname characters) Message-ID: <3E822AA2.B5D34120@mindspring.com> References: <8DBF2195-5FBF-11D7-8B57-0003930B3DA4@nostrum.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David J Duchscher wrote: > The 'national security' comment as made do the shifting of arguments. > We go to from the maxim of being generous to to accept and then to its > a security issue. With respect to the underscore character, I see this > as a week argument when balanced against the breakage that happens to > users. You mean the programs that break when they are returned an "_" from gethostbyaddr(), or the programs that "break" when they call gethostbyname() an invalid hostname containing an "_", and don't get an IP address back? The first one is the security problem. The second one is the one you apparently care about. > I would say the program is broken if it doesn't check its input. So if gethostbyname() doesn't check it's input for "_", it's broken? 8-). I think you are confusing "consumer" and "producer". A complying application would be strict in what it generates, which means it would refuse to generate gethostbyname() requests with "_" in them, for fear of breaking the programs it's making requests to. It would accept "_" in gethostbyaddr() responses. I'm not sure about that, though. Because the API boundary is an interface, then gethostbyaddr() should be strict in the responses it generates to the application making requests, and also refuse to pass them up to the application. So either way, the protocol maxim works. > If many operating systems where doing this your argument would be > much stronger. Sendmail is the majority mail server. > Secondly, we are talking about underscores in the middle of a hostname > so your example is off. OK, consider my example to move the underscore to the middle of the host name, instead. > > Mark is pointing out that this is not just a theoretical possibility, > > it was in fact exploited against sendmail on the systems you are > > holding up as examples (but it was *not* exploited on FreeBSD, > > because FreeBSD complies with RFC-952). > > And I am not advocating removal of all the checks, just he addition of > one very annoying character that cause grief to those that have to > work in a mixed OS enviroment. Are these machine generated hostnames, or human generated hostnames, and which particularly annoying environment? It's reasonable to add a compatability flag (default off) to support an annoying machine generated hostname, if there's no way to turn it off in the generation algorithm. But I've already said this, and I claim it applies to more than just "_". > >> Bypassing the resolver is also not an option that most > >> users have available to them. > > > > All programmers have this option, if they have the option to > > use the resolver in the first place. The API is well, if > > obscurely, documented. > > Users != programmers so this statement is moot. Users that simply wish > to hit a web site are the ones that bump into this issue. You really > expect them to modify code? No. I expect browser vendors to modify code. > > Note that sendmail now wraps the calls itself, in case the host OS > > is not conformant with RFC-952. You will not be able to send or > > receive email from non-compliant systems on any system running a > > corrected version of sendmail that does this enforcement. > > Just so you know, sendmail does not conform to RFC 952. It protects > itself sure, > but it allows host names to have an underscore in the host name if the > underline > resolver allows. I have not tested this beyond a couple of machines > but this seems > to be the case. What version is your sendmail? > > I have no objection, in principle, to such a patch, as long as > > it's not enabled by the default configuration distributed with > > the system. > > > > HOWEVER, this particular patch is not sufficient to put the > > argument to rest. > > > > This should probably not be "allow_underscore" in the resolv.conf. > > > > Instead, you should probably have: > > > > allow_chars "_" > > > > You will also need an escape charachter, which is usually "\", > > for specifying things like the escape character, special characters, > > and quotation marks, e.g.: > > > > allow_chars "_\\\010\x17\"" > > > > Since the systems you are talking about are broken vs. RFC-952 for > > more than just underscore. > > > > Otherwise, next week, we are going to have people asking us to > > allow the next character not in RFC-952, and there will be a > > proliferation of these options. > > I don't really agree that their will be proliferation of addition > characters. Why not? If this is one jackass vendor machine-generating names with _ in them for DHCP lease additions to the local DNS in order to cause problems for UNIX systems, then they will certainly notice the change, and make their own changes to *keep* things difficult for UNIX vendors, won't they? -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E822AA2.B5D34120>