From owner-freebsd-security  Wed Jan 26  3:14:58 2000
Delivered-To: freebsd-security@freebsd.org
Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4])
	by hub.freebsd.org (Postfix) with ESMTP id 94CA0151DE
	for <security@FreeBSD.ORG>; Wed, 26 Jan 2000 03:14:54 -0800 (PST)
	(envelope-from freebsd@gndrsh.dnsmgr.net)
Received: (from freebsd@localhost)
	by gndrsh.dnsmgr.net (8.9.3/8.9.3) id DAA74269;
	Wed, 26 Jan 2000 03:14:38 -0800 (PST)
	(envelope-from freebsd)
From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>
Message-Id: <200001261114.DAA74269@gndrsh.dnsmgr.net>
Subject: Re: Merged patches
In-Reply-To: <200001260011.QAA28012@salsa.gv.tsc.tdk.com> from Don Lewis at "Jan 25, 2000 04:11:39 pm"
To: Don.Lewis@tsc.tdk.com (Don Lewis)
Date: Wed, 26 Jan 2000 03:14:38 -0800 (PST)
Cc: dillon@apollo.backplane.com (Matthew Dillon),
	imp@village.org (Warner Losh), security@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-security@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

> On Jan 25, 11:34am, "Rodney W. Grimes" wrote:
> } Subject: Re: Merged patches
> } >     I found a bug in the patch:
> } > 
> } > : #endif
> } > :-		if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)))
> } > :-			goto drop;
> } > :+		if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) ||
> } > :+		    IN_MULTICAST(ntohl(ip->ip_src.s_addr)) ||
> } > :+		    IN_EXPERIMENTAL(ntohl(ip->ip_src.s_addr)))
> } 
> } And yet another bugger.... you just made it impossible for anyone
> } doing work with the EXPERIMENTAL block at 240.0.0.0/8 on FreeBSD
> } using TCP without hacking the kernel code.  Please remove the
> } last check here.
> 
> How about changing the last part to to
> 	ip->ip_src.s_addr == htonl(INADDR_BROADCAST)
> which is the subset of IN_EXPERIMENTAL that I was concerned about.
> 
> Without this, someone will post yet another variant of this attack
> using a broadcast source address.

The short and simple answer:
ipfw add deny ip from 240.0.0.0/4 to any

The longer answer:
Manning is not very clear on Class E space, Technically 255.255.255.255
is a class E address, and is part of ``a range left unspecified''.  Putting
your patch above in would be ``specifing'' a behavior.  But yet Manning
later says:

	Note:  No addresses are allowed with the four highest-order bits
	set to 1-1-1-1.  These addresses, called "classE", are reserved.

Reserved means we should not be putting in hard code that effects how
they behave, IMNSO.

Your going to have to do the short and simple answer covers to cover
the other parts of this space anyway, so you might as well only do it
one place and not create what may be a headache for someone else.

Also don't some strange clients like DHCP use this as a source address
during their startup phase?

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)               rgrimes@gndrsh.dnsmgr.net


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message