From owner-freebsd-stable@FreeBSD.ORG Tue Nov 26 02:02:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0BF7E94 for ; Tue, 26 Nov 2013 02:02:23 +0000 (UTC) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8F976295B for ; Tue, 26 Nov 2013 02:02:23 +0000 (UTC) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id C7939C94D9; Tue, 26 Nov 2013 02:02:09 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1385431343; bh=4TbTRqKU+rzVosAIHmy0ZsmjLEHmueergm6rtXgWvi8=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=i5/S98w5fswRzXBojIQQCoqZ9Ikjecxdod3HRcK2bArx2hhjQVllxQvk+bStwcmwj ncG4I9xBjFS/ULmcwzLIY51eZ5H7IdFb6u648xPOQWhpaqn5yYPGIWPI0olXUUEo1i zIcMW3cKlMkewcqxVl2R3fDGaEDCnU2et4xjjIm4= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 26 Nov 2013 02:02:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 6A9FA160436; Tue, 26 Nov 2013 02:09:22 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 0F30916042E; Tue, 26 Nov 2013 02:09:22 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 37AF9AD4D2C; Tue, 26 Nov 2013 13:02:08 +1100 (EST) To: Michael Butler From: Mark Andrews References: <52911993.8010108@ipfw.ru> <529259DE.2040701@FreeBSD.org> <20131125152238.S78756@sola.nimnet.asn.au> <1385391778.1220.4.camel@revolution.hippie.lan> <20131126001806.27951AD3DBF@rock.dv.isc.org> <5293EBD6.8010009@protected-networks.net> <20131126003941.1ACD9AD41B4@rock.dv.isc.org> <5293F9D1.2030800@protected-networks.net> Subject: Re: ipfw table add problem In-reply-to: Your message of "Mon, 25 Nov 2013 20:30:57 -0500." <5293F9D1.2030800@protected-networks.net> Date: Tue, 26 Nov 2013 13:02:07 +1100 Message-Id: <20131126020208.37AF9AD4D2C@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mx.pao1.isc.org Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 02:02:23 -0000 I remember incorrectly, the actual change was this one. revision 1.8 date: 2001-07-16 13:22:24 +1000; author: marka; state: Exp; lines: +4 -2; 1242. [bug] inet_pton() failed to reject octal input. Index: inet/inet_pton.c =================================================================== RCS file: /proj/cvs/prod/bind8/src/lib/inet/inet_pton.c,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- inet/inet_pton.c 13 Oct 1999 16:39:28 -0000 1.7 +++ inet/inet_pton.c 16 Jul 2001 03:22:24 -0000 1.8 @@ -16,7 +16,7 @@ */ #if defined(LIBC_SCCS) && !defined(lint) -static const char rcsid[] = "$Id: inet_pton.c,v 1.7 1999-10-13 16:39:28 vixie Exp $"; +static const char rcsid[] = "$Id: inet_pton.c,v 1.8 2001-07-16 03:22:24 marka Exp $"; #endif /* LIBC_SCCS and not lint */ #include "port_before.h" @@ -95,10 +95,12 @@ if ((pch = strchr(digits, ch)) != NULL) { u_int new = *tp * 10 + (pch - digits); + if (saw_digit && *tp == 0) + return (0); if (new > 255) return (0); *tp = new; - if (! saw_digit) { + if (!saw_digit) { if (++octets > 4) return (0); saw_digit = 1; Now if you want to make it accept 0+[89][0-9]* go ahead but 0+[01234567][01234567]* need to be rejected when the inet_aton accepts octal and hexadecimal. Having different routines return different values for 070.070.070.070 is infintitely worse than having 070.070.070.070 be rejected by one. Yes there is a small subset of 8 octal inputs that match decimal input for which there is no harm. I'm much more worried about the ones that do differ. Mark In message <5293F9D1.2030800@protected-networks.net>, Michael Butler writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/25/13 19:39, Mark Andrews wrote: > > >> When inet_pton() implementations have been rejecting leading zero's since > >> they were first written their can't be a POLA. There can be a difference > >> but not a POLA. To make is now accept a leading zero would be a POLA as > >> there is code that depends on leading zeros being rejected by it. > > History disagrees with you; from the BIND 4 sources: > > /* This is from the BIND 4.9.4 release, modified to compile by itself */ > > /* Copyright (c) 1996 by Internet Software Consortium. > * > * Permission to use, copy, modify, and distribute this software for any > * purpose with or without fee is hereby granted, provided that the above > * copyright notice and this permission notice appear in all copies. > * > * THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM > DISCLAIMS > * ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED > WARRANTIES > * OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL INTERNET SOFTWARE > * CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL > * DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR > * PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS > * ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE > OF THIS > * SOFTWARE. > */ > > #if defined(LIBC_SCCS) && !defined(lint) > static char rcsid[] = "$Id: inet_pton.c,v 8.6 1996/06/26 23:17:26 vixie > Exp $"; > #endif /* LIBC_SCCS and not lint */ > > [ .. snip .. ] > > /* int > * inet_pton4(src, dst) > * like inet_aton() but without all the hexadecimal and shorthand. > * return: > * 1 if `src' is a valid dotted quad, else 0. > * notice: > * does not touch `dst' unless it's returning 1. > * author: > * Paul Vixie, 1996. > */ > static int > inet_pton4(src, dst) > const char *src; > u_char *dst; > { > static const char digits[] = "0123456789"; > int saw_digit, octets, ch; > u_char tmp[INADDRSZ], *tp; > > saw_digit = 0; > octets = 0; > *(tp = tmp) = 0; > while ((ch = *src++) != '\0') { > const char *pch; > > if ((pch = strchr(digits, ch)) != NULL) { > u_int new = *tp * 10 + (pch - digits); > > if (new > 255) > return (0); > *tp = new; > if (! saw_digit) { > if (++octets > 4) > return (0); > saw_digit = 1; > } > } else if (ch == '.' && saw_digit) { > if (octets == 4) > return (0); > *++tp = 0; > saw_digit = 0; > } else > return (0); > } > if (octets < 4) > return (0); > /* bcopy(tmp, dst, INADDRSZ); */ > memcpy(dst, tmp, INADDRSZ); > return (1); > } > > Note especially that at some time after 1996, an additional two lines > were added and the man page not updated to reflect their addition. > > Above the test "(new > 255)" these lines were added: > > if (saw_digit && *tp == 0) > return (0); > > .. and which now causes this confusion. > > Either the code or the man page are wrong, > > imb > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.15 (FreeBSD) > > iEYEARECAAYFAlKT+dEACgkQQv9rrgRC1JJOxwCgpqtkHUv+d15C49JPpnNrwPI/ > zrkAmwSXukkcAhAKKfteEuFRe7tbTqnT > =1JzH > -----END PGP SIGNATURE----- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org