On Sat, Jan 11, 2003 at 11:24:39AM -0500, Andrew Brown wrote:
> i won't pretend to have read the paper very closely, but i did skim
> it, i do think i understand the issue at hand, and i think the closing
> quip of "just how secure is your vlan" is a silly question.  the
> answer, of course, is "not as secure as my physical lan".
> 
> >That said, I agree with the other posters - it seems like a tempest in a 
> >teapot to me.
> 
> yea, verily.  i have some (mostly rhetorical) questions about the
> testing.
> 
> (1) how do you know the machine that was doing the sniffing isn't
> inserting the padding?

because it has to be inserted by the transmiter. The ethernet standart
requires it.

> 
> (2) how do you know the nic being used on the sniffer machine isn't
> doing the padding?

Same as (1)

> 
> (3) how do you determine that the padding is being done by the remote
> operating system and not by the remote nic?

I think you can't really know without looking at the driver. All you can tell
is if the remote is vulnerable or not (and it may be the nic doing the padding,
but doing it wrong).


> 
> (4) how do you determine that the intermediate networking equipment
> (hubs and/or switches) isn't doing the padding?

Hubs won't. switches may do it, if the media isn't the same on both sides
(like e.g ethernet VLANs over ATM)
> 
> (5) how do you determine that the data is "sensitive" and not merely
> an accidental resending of data that was already picked up from the
> network?

This is the harder part, but I won't claim it's not possible for someone
specialised in this kind of thing. And even if it's data already
received or sent to network, it can still be sensitive (it can comes from
loopback, or from another NIC on a trusted LAN in case of a router).

> i suppose that by using four or more machines of different varieties
> (one windows 98 or windows xp, one macos, one netbsd, one openbsd,
> etc) so that operating differences would be spread out, and having all
> of them sniffing at all times so that data could be correlated and one
> could tell if they were all seeing the "extra" data...
> 
> the use of several 10mbit hubs so that no one would *miss* any data
> would also be a good idea.  as well as exchanging the hub for another
> one (or two or three) so as to eliminate *it* as a source of bad data.
> rotating a large supply of cards between the machines would also be
> good.
> 
> i didn't see any evidence in the paper of any attempt to cleanse and
> control the testing in this manner.  it seemed to concentrate mainly
> on issues with some linux drivers and gesture at the idea that other
> operating systems may be vulnerable as well.

The problem is trivial to expose with tcpdump and ping.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 23 ans d'experience feront toujours la difference
--