On Fri, 12 Apr 2002, Noonan, Wesley wrote: > > Historically, "strange" 802.1q packets on Cisco switches have worked do > > DoS the switch. Historically, forged spanning tree packets have worked to > > DoS the switch. I believe there was also an interesting MAC address > > attack using the switch's MAC, but I don't recall the details. The > > backplane isn't the issue if you can make the CPU too busy to do its job, > > especially if doing so places the device into broadcast mode. > > Turn off spanning tree?? You only need it if you have loops. Point made on > the CPU (wasn't thinking in that direction). I don't really see it as a real > problem though. I would need to see writeups to be convinced that it is a > problem, or that the switch would actually start passing traffic. I know > what *was* possible, but those problems have been fixed to my knowledge.
Known, reported and uncovered problems have been fixed in at least some implementations. If we went by that logic as "no more problems from that vector," we as an industry would get re-whacked at a much higher rate than even we're currently getting whacked at (and I'd have lost my previous job, not just gotten bored with it.) "Fixed to my knowledge" is less useful as a metric than "historically been broken" from a risk assessment viewpoint without some specific qualifications. Ones that would mean a lot to me would be things like "audited the codebase in the last year or so," "worked on the code and there's a specific process that covers this," or "have some detailed knowledge about a process or procedure and its rate of adoption at said vendor which mitigates such risks." Without additional data, or perhaps a lot of experience testing such products in such scenerios, it's really difficult to see what assurance that statement brings to the table. Now, I don't know- maybe you have this, or some similar level of assurance. I've been dealing with Cisco gear for quite a while, and I've never seen a line of IOS code- so my assurance needs to have a great deal of historical data, both vendor-specific, protocol-specific and "this sort of thing generally behaves in that way" nebulous things. Until we get things like bugs/kloc, protocol-level QA, and some set of actuarial tables for vendors and equipment, that's what I've got to go on, along with some fairly clear knowledge of how network security product vendors tend to do in testing for security features. > > By the same token, rumbles sometimes mean a storm is coming. If you've > > some information that gives an assurance that 802.1q issues have been > > examined in more significant depth, please present it. > > Unfortunately, I am in no better position than you in this case. I don't > have anything I have found. The whole "DMZ/VLAN" issue is a very hard to > find documentation on topic... 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. > > Which doesn't say that the same sort of thing won't happen for CDP (and > > the product wasn't from a vendor per-se.) The logic "Vendors who make > > switches have had issues with longer-lived protocols than the ones their > > switches use as a default to do topology related things, and it will > > likely happen again" isn't a bad jump. Please cite an SNMP ASN.1 issue > > from 10 years ago. > > The entire recent "issue" with SNMP revolved around *known* issues with SNMP > V1 that had existed since it's inception. I would with a guy that sits on > the IEEE committee. I have heard *all* too much about this problem as he has > scrambled to try to address it... 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? Now, since most of the same vendors had to fix ASN.1 LDAP issues a year or so prior, do you expect we should have trusted them to fix all the ASN.1 issues a couple years ago when the LDAP protocol exerciser was released? Because that seems to me to be what you're arguing here, and I can't imagine we'd even have firewalls if we expected vendors to fix all the bugs once and for all. > > 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?) 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.) Is it possible that Cat5000s now send traffic only to specific ports instead of sending to all ports then telling the non-recipient ports to drop frames not destined to them? Sure it is, in fact, I *hope* they work that way now. Do I believe that the original design parameters of Cisco switches were revisited from the top down when VLANs became the rage? Nope. Could they have? Sure, but absent evidence and absent checking to see if "Cisco LAN Switching" has been completely updated in the last 18 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. > nothing necessarily wrong with this, you have a perception on this list as > someone who is "in the know". That is cool and all, but that sometimes leads > to people taking your opinion as fact and then moving forward as if "that's > the way it works". That kind of misinformation, intentional or otherwise > (and no, I don't think you intentionally do it) is a bad thing. I try to present "know" versus "think" versus "historical" using pretty clear terms every time. Like any evaluation, you have to understand the language of the evaluator and question assumptions, 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! > Yes, in the *past* switches could be exploited during a failure by them > passing data between VLANs that they shouldn't. I don't know of a single > *current* exploit that exists that way though. While it may exist, since no > one seems to be able to point it out, much less refer to it with anything or > more substance than historic anecdotal evidence, I just think the > credibility today is probably not very good anymore. 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. > 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. Internal/External VLANS are a bad idea from a security architecture standpoint. > > *and* in a multiple switch > > enviornment, unless you're creating one big logical switch by hooking them > > directly together, there's a layer 3 device in the middle that will likely > > have more security attention paid to it (in the specific example in this > > thread it was a PIX) than the switch generally gets- > > But this is still true with a VLAN switch. No, unfortunately it's not still true- if the switch is mostly "internal" with a single "external" segment, it'll have less security attention and care and feeding than will the PIX. I'd bet on that for at least 20% of installations. In a lot of companies, firewall admin != switch admin. Giving people an architecture that will probably fail 1 in 5 times isn't my idea of a good thing[1]. > > especially when the > > switch's maintenance is dictated by any issues on the internal network. > > Now this is the first point that you might have some validity on (I say > might because it is still debatable). _Everything_ is debatable, and there are instatantiation-specific issues and cures that aren't always accountable for without making a conversation unintelligible. That doesn't make the value of the conversation (nor the debate) worthwhile. There's a strong reason that physical compartmentalization has been an essential part of good security practices since the dawn of time- and it's not just a pure dogma issue. The complexity of "Turn off spanning tree," "Turn off CDP," "make sure the DMZ is never trunked with an internal VLAN," "Make sure that an internal server is never plugged into an external port on that box (including when you're swapping wires,)" "Ensure that the config hasn't been changed every time someone leaves," "Believe that all the 802.1q issues have been solved for this switch and its OS," "Believe that all the Ethernet issues have been solved for this switch and its OS," "Hope there's never a worm that exploits the "trusted" side of the switch," and "Believe the failure modes of switches have changed from internal "get the traffic delivered" to a higher threat condition?" compared to "Buy a small switch and external stuff gets plugged in over there." is a no-brainer in my book. Paul [1] Our statistics show that ~ 3 in every 5 firewalls isn't configured to block attacks it is capable of blocking- I doubt switch configuration is done significantly better, but our true study is 3yrs old- so you'll have to disbelieve it or take my word that it hasn't changed much over that time. ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions [EMAIL PROTECTED] which may have no basis whatsoever in fact." _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
