From owner-freebsd-hackers  Fri Mar  1 13:38:32 2002
Delivered-To: freebsd-hackers@freebsd.org
Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12])
	by hub.freebsd.org (Postfix) with ESMTP id 1335137B400
	for <hackers@freebsd.org>; Fri,  1 Mar 2002 13:38:30 -0800 (PST)
Received: from pool0405.cvx40-bradley.dialup.earthlink.net ([216.244.43.150] helo=mindspring.com)
	by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1)
	id 16gujA-0001Sd-00; Fri, 01 Mar 2002 13:38:09 -0800
Message-ID: <3C7FF481.991305A7@mindspring.com>
Date: Fri, 01 Mar 2002 13:37:05 -0800
From: Terry Lambert <tlambert2@mindspring.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Leo Bicknell <bicknell@ufp.org>
Cc: Luigi Rizzo <rizzo@icir.org>, Bob Bishop <rb@gid.co.uk>,
	"George V. Neville-Neil" <gnn@neville-neil.com>,
	Doug Ambrisko <ambrisko@ambrisko.com>, hackers@FreeBSD.ORG
Subject: Re: Multicast problem with sis interface?
References: <200203010557.VAA1802420@meer.meer.net> <rb@gid.co.uk> <4.3.2.7.2.20020222165515.00c14850@gid.co.uk> <200203010557.VAA1802420@meer.meer.net> <4.3.2.7.2.20020301112956.00c5b550@gid.co.uk> <20020301035623.A32974@iguana.icir.org> <20020301184123.GA5908@ussenterprise.ufp.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-hackers.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-hackers>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-hackers>
X-Loop: FreeBSD.ORG

Leo Bicknell wrote:
> I point out both of these are security risks.  Granted, fairly
> minor, but they allow someone to get all/part of a previous packet's
> data, when they should have it.  This sort of thing has been used
> as an attack vector before.  I think fixing these to pad with some
> generated (0's, 1's, /dev/random, whatever) should be a top priority.

Not /dev/random.  It's going to be ignored as invalid
anyway, since it's after the end of the packet according
to the length.  So it's not like trying to obfuscate it
will magically put an attacker at some disadvantage.

-- Terry

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