[28545] in bugtraq
Re: More information regarding Etherleak
daemon@ATHENA.MIT.EDU (Manuel Bouyer)
Wed Jan 22 10:39:32 2003
Date: Fri, 17 Jan 2003 18:51:40 +0100
From: Manuel Bouyer <bouyer@antioche.lip6.fr>
To: Peter Turczak <p_turczak@wiwa.de>
Message-ID: <20030117175140.GB12482@antioche.lip6.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200301171825.54288.p_turczak@wiwa.de>
On Fri, Jan 17, 2003 at 06:25:52PM +0100, Peter Turczak wrote:
> Well this correct as long as you don't use the Sun fcal and gbit card. This
Strange, all gbic atapters I know do automatic padding
> one does again not pad with a constant value, so i guess it is vunerable.
>
> 0000 00 0a 27 7d d2 c6 08 00 20 fc e9 ca 08 00 45 00 ..'}.... .....E.
> 0010 00 1d af d7 40 00 ff 01 45 c8 c0 a8 02 28 c0 a8 ....@...E....(..
> 0020 02 c7 00 00 8c a9 73 4c 00 0a 00 00 00 00 00 00 ......sL........
> 0030 00 00 00 00 00 00 00 00 00 00 00 00 31 48 fe 98 ............1H..
> Interesting is that most bytes of the pad are zero, but the last four are not,
> this is correct for all packets i got out of our Sun.
Ha, how long is your packet ? 60 or 64 byte ?
If it's 64 then the 4 last bytes are the ethernet CRC. I also made this
mistake when testing some drivers, until I noticed the len was not what I
expected it to be :)
As you seem to have captured a multiple of 16 bytes, I suspest it's 64...
--
Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr
NetBSD: 23 ans d'experience feront toujours la difference
--
