On Fri, 12 Apr 2002, Noonan, Wesley wrote:
>
> Sure, but passing FUD isn't really helpful either. People need to make
> informed, insightful and proven statements. Not "well this could happen, so
> it's bad".
Much of security is related to this might happen so don't do this. Much
is also based upon what has happened in the past. Thus many folks have
moved awa from sendmail, wu_ftpd, BIND and other aplpications that have
'bad histories', it matters not to those that have removed these tools
from their tool boxes that newer versions have fixed known issues, the
fact remains they have bad *histories* and so they are either removed or
notably tamed and neutered.
>
> > People who's abilities I have a high degree of trust in have claimed some
> > interesting results from their testing. They don't do exploits- so no
> > "earthshattering" reports from customers, but neither do they necessarily
> > do vendor reports. If I had more time, I'd start playing a lot more with
> > code, but it's pretty far down my list of things and I don't see that
> > happening anytime soon.
>
> Until then though, FUD winds up getting passed around as fact.
>
I see no FUD, I do see an experienced security person passing knowledge he
has gleened from years in the field and many years in the security related
lists. Well tempered knowledge being shared.
> > If it's indeed been known for 10 years that the ASN.1 encoding/decoding
> > routines had implementation problems then I'm *glad* they're scrambling-
> > it's
> > not a protocol problem, it's an implementation problem and 10 years is
> > long
> > enough to fix an implementation's buffer size, no?
>
> Sure it is. That's one of the problems with an effectively open-source
> development effort though. No organized and accountable QA. Development can
> stick to their "it's not a bug, it was designed this way" mantra.
>
Of course closed source QA has worked well for the likes of M$ and others
through the years. How long did it take for the most secure version of
windows ever to have issues posted to bugtraq? Did it take a full week?
> > > > The FACT stands that switches have traditionally had failure modes
> > that
> > > > resulted in every packet going out of every port (historically, for
> > Cisco
> > > > the easiest of those was filling up the CAM table- there have been
> > > > others and Cisco isn't the only vendor.) Absent evidence that
> > > > such failure modes have been changed due to the proliferation of VLANs
> > on
> > > > switches, there exists doubt. Your evaluation of the credibility of
> > the
> > > > statement is neither here nor there in regards to how it is offered.
> > > > Since I SAID "I'm not sure...," it's obviously not completely
> > informed-
> > > > which is WHY I said it that way- sheesh.
> > >
> > > Here's the problem Paul. You present a *lot* of opinion as fact on this
> > > list. In fact, you are doing that in the above statement. While there is
> >
> > Are you asserting that filling the CAM table on a Cisco switch never
> > triggered a "go into hub mode" failure? Are you asserting that my
> > statement that it isn't the only vulnerability that ever made a Cisco
> > switch act like a hub (hint: CPU starvation on a Cat5000 is another?)
>
> No, I'm not.
Then some of us would really like to know what you are seriously claming
concerning switches as security devices.
>
> > Those are the two statements above that are stated as fact. The "Absent
> > evidence" part is an invitation to provide such, because I certainly
> > haven't
> > seen it (nor do I have faith in every switch vendor on the planet not
> > making
> > the same types of mistakes.)
>
> Paul, I am not focusing in on any one statement of yours, but rather a
> general observation of the way you present information.
>
<shakes his head in puzzlement>
> <snip>
> > months or so, I'll go with caution. If you've got any URLs that mention
> > any such changes, I'd certainly appreciate the data.
>
> No, I don't but that is my point. I don't believe in making alarmist
> statements either. I deal in facts and what can be proven, not something
> that might be plausible but no one knows, or at least no one seems to know.
>
Paul is not stating anything that has not been stated by countless others
in this list and other lists you probably do not read Wesley. Switches
are not security devices, and those using them in any security context
need to do so with extreme caution at the least.
> <snip>
> > assertions and methods. When you go out of your way to say "I'm not
> > sure..." it's pretty frustrating to have someone say "Hey- you're not sure
> > about that" as if it were a revelation!
>
> That's the difference between you and I, I suppose. I don't say "I'm not
> sure..." then try to tell people what is/is not good design.
>
> > It's been what, about 2 1/2 years since the initial tagged queueing stuff
> > was done? Are you saying "there are no coded 802.1q exploits in the
> > last two years," or "There are no switches vulnerable to an 802.1q exploit
> > today," "Cisco fixed the 802.1q issues that were pointed out to them," or
> > "Cisco fixed all their 802.1q problems?" It's not clear here which you're
> > saying, and I've got 4 CDs *full* of exploits to go over in the next
> > month, so I'd like to know which thing I should be looking for.
>
> I said it before and I will say it again. I don't *know* that those exploits
> don't exist any more than you apparently know that they do. However, unlike
> you, I am not going to sit here and tell people using VLANs is good or bad
> since the reality is that I can't find anything of substance to say it is/is
> not.
>
What it's boiling down to then is you just want to argue with Paul and his
'style', it's not that you have any serious information on the topic to
share?
> > > You can do this in a single switch environment *too*. Bad design is not
> > a
> > > uniquely VLAN problem.
> >
> > Cool, please show me a single switch design where the *default* switch OS
> > with a *default* configuration does this. I'm not, and have never said
> > bad design was uniquely a VLAN problem, I'm saying you have to try
> > significantly harder to not make it one in a VLAN environment.
>
> Let's see... when Bucky the network admin indiscriminately starts plugging
> cables in?
>
> > Internal/External VLANS are a bad idea from a security architecture
> > standpoint.
>
> Here you go making this statement again, but I am not seeing it backed by
> anything other than outdated anecdotal evidence. This is your opinion, an
> opinion that you have not been able to defend very well IMHO.
>
I have on record here a cisco advisory on their switch products dating
back to as early as January, hardly ancient history as some have suggested
here affecting these devices at least:
* Catalyst 6000 series
* Catalyst 5000 series
* Catalyst 4000 series
* Catalyst 2948G
* Catalyst 2900
Cisco Security Advisory: Cisco CatOS Telnet Buffer Vulnerability
================================================================
and I have here stuff on arp spoofing and CAM table flooding only dating
back to 1998, mudge's stuff on how he and the l0pht folks misplayed
switches dating to 2000, neither of those dates being -=ancient=- in
historical terms, even in IT/Internet terms. Nor does it mean that each
site employing switches has patched and updated those vulnerabilites that
might have been corrected, by cisco and other vendors. I do have
advisories for other vendors on hand more current the this past January.
Just because Paul does not keep on hand all the advisories or postings of
folks that have worked switch exploits for easy retrieval to enhance his
recollections and premisses each time this topic pops up in this list,
does not invalidate those recollections and his premisses.
This is an old repeated topic on this and other lists, do some reaserch.
[SNIP'ed the rest of the crud]
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]
http://lists.gnac.net/mailman/listinfo/firewalls
