From owner-freebsd-stable@FreeBSD.ORG Wed Mar 26 00:48:47 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EC2837B404 for ; Wed, 26 Mar 2003 00:48:47 -0800 (PST) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D83C43FAF for ; Wed, 26 Mar 2003 00:48:47 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0122.cvx21-bradley.dialup.earthlink.net ([209.179.192.122] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18y6aL-0006cI-00; Wed, 26 Mar 2003 00:48:38 -0800 Message-ID: <3E816913.2B3E614E@mindspring.com> Date: Wed, 26 Mar 2003 00:47:15 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David J Duchscher References: <460D1DA6-5F59-11D7-BFC4-0003930B3DA4@nostrum.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4ed3e4f265b2a4d259ddb7b98e56ad592667c3043c0873f7e350badd9bab72f9c350badd9bab72f9c X-Spam-Status: No, hits=-21.7 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_UNCONFIRMED_DSBL,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: stable@freebsd.org cc: Mark_Andrews@isc.org Subject: Re: Resolver Issues (non valid hostname characters) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2003 08:48:48 -0000 David J Duchscher wrote: > On Tuesday, March 25, 2003, at 11:23 PM, Mark.Andrews@isc.org wrote: > > This is a security matter. Sendmail was compromised due to > > lack of checking the results returned by gethostbyaddr(). > > > > get*by*() and get*info() enforce RFC 952 so that every > > application written doesn't have to validate the results > > returned. Allowing underscore (or IHN) is a API change > > and will potentially break applications that correctly > > depend upon get*by*() and get*info() filtering out the > > garbage. > > > > If you want to be liberal in what you accept bypass > > get*by*() and get*info() and call the resolver directly. > > Let me see, this is a matter of national security so we can't talk > about it. This is very much a straw man argument when it comes to > underscore. It's not "national security", it's "computer security". If you allow crap in host names, code which operates on host names, and uses globbing code which does not proactively ensure that the characters are escaped before applying globbing rules, particularly interpreted globbing code, becomes vulnerable to exploits. Specifically, say I have an interpreter that interprets variables with an underscore prefix. By contacting my server written in this interpreter from a host whose reverse address has been set to include this character, you could exploit the fact that people who call the resolver library expect strict RFC-952 conformnace in the returned host names, and obtain escalated priviledges on my server system. 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). > 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. > This argument also implies that all the other OS mentioned have > a security problem because they don't do this type of checking. They do, if they are running a version of sendmail which does not specifically provide it's own wrappers, ensuring RFC-952 conformance. Check the CERT advisories. 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. > > If the name contains a underscore it is not a hostname by > > definition. Nothing stops you talking to the DNS directly > > and entering IP literals. > > CNAME virtual hosts. > > I have mailed the patch to PR/50299 that makes it an optional behavior. > You can also find it here: > > http://magus.nostrum.com/~daved/resolver_patch.txt 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. -- Terry