From owner-freebsd-security Tue Oct 6 09:49:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA24914 for freebsd-security-outgoing; Tue, 6 Oct 1998 09:49:56 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (COPLAND.CODA.CS.CMU.EDU [128.2.222.48]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA24901 for ; Tue, 6 Oct 1998 09:49:53 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id MAA27809; Tue, 6 Oct 1998 12:47:18 -0400 (EDT) Date: Tue, 6 Oct 1998 12:47:18 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Michael Richards <026809r@dragon.acadiau.ca> cc: security@FreeBSD.ORG Subject: Re: Large packets? In-Reply-To: <199810061502.MAA01110@dragon.acadiau.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 6 Oct 1998, Michael Richards wrote: > I have been following the discussion of negative IP addresses. Correct me if > I am wrong, but isn't the largest possible packet 64K even after it's been > re-assembled? In theory. :) The maximum size of an IP packet is indeed 64k, but some implementations don't check that the fragments being reassembled actually add up to the correct length, so they just past the fragments one after another, off the end of the buffer, onto the floor. Or rather, onto other pieces of memory resulting in corruption. My speculation about the negative number being associated with size was based on this -- that perhaps some careless programmer had accidentally used a signed short for the size in their code, rather than an unsigned short. Then any check against the size field in the form if (size < somesize) would behave incorrectly, because large packet sizes would be interpretted as small ones. Darren has suggested that I am confusing this with another attack, and that is entirely possible. :) The are an awful lot of mistakes an IP stack programmer can make :). Robert N Watson Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message