On Tue, 21 May 2002, Noonan, Wesley wrote:
> Yeah.
>
> I'm not the guy needing "clueing in", but I think that you are. This isn't
> beating a dead horse, this is an entirely different and new horse that has
> nothing what-so-ever to do with the dead one.
are you certain?
>
> In case you missed it, and it is clear you did, I NEVER PRESENTED ANY
> POSITION ON THE SUBJECT OF VLANS IN A DMZ, PRO OR CON. In fact, I made it
> PERFECTLY CLEAR that I generally recommend the use of HUBS in DMZ's, not
> switches and not switches with VLANs. What I did do is ask for people to
> present *factual* evidence about the supposed problem, which no one could
> beyond historical (and long since patched), situations. In fact, you still
> don't seem to be able to refer to any timely information on the subject,
> including this exploit (which you completely misconstrue).
>
<chuckle> Damn! <we are awaiting to see how many broked content scanners
are going to go nuts here, sicne it's already demonstrated that 'bitch' is
so offnesive to so many> It's getting to easy, not even a challenge
these days, to get a rise outta ya <grin>.
Yet, I tend to think that it remains a mistake to ignore historical
reference, see below;
> Just to further clarify the FUD that you, Ron, seem to like throwing around
> in regards to VLANs, read the exploit again. It's a single VLAN exploit, not
> a multiple VLAN exploit. The data is being flooded to all ports on a single
> VLAN - not from one VLAN to another. As a result, this would happen with a
> single switch and a single VLAN in place (which is, oddly enough, exactly
> what the bug report states). What's more though, the problem does not occur
> what-so-ever when using the default VLAN (and since 99% of single VLAN
> implementations use the default VLAN, that further underscores the
> insignificance of the problem). In fact, the scenario defined makes it
> explicit that this is a "Single VLAN" (see the environment section for
> clarification of this point) problem, which does NOTHING to bolster your
> VLANS and DMZs statements. If anything, it further underscores that you can
> not present real credible reasons to not use VLANs for DMZ purposes, but
> must instead rely on FUD and misinformation to try to make your point.
>
Does this imply that all other VLAN implimentations are not vulnerable?
Perhaps, perhaps not, it may well remain to be seen.
Yet, on a historical note, the fact that this is *normal* traaffic that is
passing, no exploit required nor intended for this to happen, makes one
wonder how secure any VLAN setup is under harsher condistions.
Additionally, there is a strong hint there that this might well be tied to
older exploitable conditions; i.e. cam table flooding and MAC address
spoofing.
<quote>
Workaround:
Setting the CAM agingtime to a larger time _helps_ but does not
completely eliminate the problem. "set cam agingtime xx 14400" where xx is
VLAN #.
</quote>
> Me thinks you need to read up on how switches and VLANs work, and more so,
> you need to make sure you understand the problems and exploits before you go
> speaking about them. Heck, even this bug report makes it clear that there is
> no known exploit, and anyone who knows anything about switches can clearly
> see that, while this certainly should not be happening, the end result is
> nothing more than the switch acting like a hub in the given circumstances.
>
This report makes it clear no exploit is needed, not that one needs to be
written up:
<quote>
...
However, what is happening, is that TCP session packets are being flooded,
although the switch _should_ have learned
the MAC.
...
I have captured telnet sessions, ftp sessions, etc; with a portion of a
telnet session's password visible. There is no
special setup required to see this other than physical Ethernet connection
& sniffer software.
...
Exploit:
Patience
...
</quote>
> While I appreciate the point, however incorrect and misguided, that you are
> trying to make, I fail to see how this exploit does anything to bolster the
> previously mentioned and discussed "packets traversing VLANs" exploits that
> you dredge up from history.
>
I think what was presented in the advisory is enough to ake all secrurity
related implimentations of VLAN/DMZ etups suspect, until at least cisco
comes up with a fix. Of course, this does not speak to the
implimentations of other switch vendors, of which there are some.
> Awaiting your response, and please try to make sure there is some validity
> in it before you post it.
>
<chuckle> You get so 'cute' when yer fingers get all red pounding out
frustrations!
Thanks,
Ron DuFresne
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity. It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
***testing, only testing, and damn good at it too!***
OK, so you're a Ph.D. Just don't touch anything.
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
For Account Management (unsubscribe, get/change password, etc) Please go to:
http://lists.gnac.net/mailman/listinfo/firewalls
