Slashdot Mirror
Malformed Packet Causes Cisco Router DoS
MoreBeer writes "Patch 'em if you've got 'em... Cisco Security Advisory: Cisco IOS Malformed OSPF Packet Causes Reload states that a malformed OSPF packet can cause a router 'reload' (reboot). Vulnerable IOS versions include 12.0S, 12.2, and 12.3 ... If you're not screening OSPF at your perimeter and using OSPF Authentication, now would be a GREAT time to start."
"... If you have a glaring security hole, you better tell everybody to patch it because you risk losing your rep..."
If you spent that much on the product, you should be the emails lists about that product. If you really spent a lot, there are plenty of companies that have closed lists for dissemenating exploit info extremely quickly...to the people that should know about it (ie, the people that HAVE the product. If you love reading that companies have fixed things so much, dig about on the site and find the pages with that info...not the front page. i understand what you are saying, but i'm trying to explain to the OP why this might not be on the front page of the site.
We are just going to have to agree to disagree.
I think security (especially patches for known exploits) should be as public as possible. The trouble-makers scan the security mailing lists more than the average device owner.
btw, great pics on your site.
I don't have to patch a single router. We don't use OSPF and it isn't turned on by default. This isn't like there is some hidden service that I'm not expecting the device to be running and now I must absolutely patch.
I don't want knowledge. I want certainty. - Law, David Bowie
Not to call you out, but you are pretty screwed when it comes to routers, honestly Juniper is the only other choice for most of this scenario. Honestly Cisco is the best / only choice for many environments. Personally I like Juniper for the Nettoons http://www.juniper.net/nettoons/
A few years ago I worked at a place where we had two Cisco PIX (the 1U widgets, dunno what model, sorry) in a failover configuration. For those that don't know, you can run two kinds- stateful and non-stateful failover.
In stateful failover mode, the two units share their connection state info over a dedicated ethernet crossover cable- in theory, if one unit's hardware shits the bed, the other one immediately notices and takes over, and all users will notice is maybe a few seconds pause in everything, if that. It's all very clean and good, the slave even takes over the MAC address of the failed unit (something they've patented, and hence isn't useable in Linux HA; Linux has to force an ARP announcement, which is messier. Goooooo Cisco!)
Anyway, that's great, except when you have a software defect. Oh, say...where the PIX OS (PIXes didn't run IOS or whatever, they ran a separate OS unique to the PIX family) gets into a certain situation based on state and locks up hard.
Well, guess what happens to its twin, running the same PIX OS version, and sharing the same data? Yup, it crashes too.
The pair actually did it once right in front of us- one stopped blinking its lights...the master/slave light blipped on the backup unit, and then a few seconds later, it too crashed- and everything ground to a halt.
It was terribly amusing that Cisco was incompetent enough to not include a hardware watchdog in the PIX box so that if it hung it would reboot itself; my Sonicwall SOHO has this, why can't a PIX for chrissakes? The problem only happened every few days, and would have been manageable(ie ignorable ;-) if they had both simply rebooted themselves. Instead, someone had to trundle in and power cycle both of them, until we figured out that it was state-based, and disabled stateful failover. Then someone just had to check every day to make sure one of them hadn't kicked the bucket.
Please help metamoderate.
Step 1.) Tell customer to upgrade ios even though you cannot pin point a root cause or data that supports this as a reasonable solution.
Step 2.) Tell customer they have a worm running rampant in the network. When asked by the customer why you think this is the case, do not repond for several days. When you do respond, ask only if they have taken care of the worm.
CINCINNATI BELL IS TEH SUCK.
Asterik is a wonderful little system that I have been a fan of for quite a while. I cannot wait until it can support the large type of environment I generally build and support.
VoATM and VoFR is really not a big deal when you get into it, just a few extra caveats to watch out for once you have a solid understanding of VOIP. I do feel the need to blast out one rant: I wish people could understand the difference between: Voice over IP, IP Telephony, Voice over Internet, and channelized toll bypass. VoIP and IP Telephony get such a bad rap on /. and elsewhere when people are using non QOS devices across an uncontrolled media to try to deliver voice packets in a timely manner over the internet. End rant, my apologies to all innocent bystanders.
"compatable"? Are you kidding?! [E]IGRP is Cisco's proprietry [and patented] routing protocol. However, it is very well publicly documented. If EVERY network device needing to participate in routing is made by Cisco, then yes, [E]IGRP is a good choice. However, this is rarely true and OSPF is the only viable alternative.
(BTW, Cisco supports EIGRP for more than just IP.)
"However for global organizations with multiple high-bandwidth links between branches, for example, for whom downtime costs many thousands of dollars per hour, there aren't very many options. It's a good thing that what options there are are very solid."
While I agree with almost all of your points...Dude, CISCO have a vulnerability to malformed packets and they appear to be staying quiet about it. How solid are you trying to tell people is solid? Have you ever tried to get Cisco out to swap out a router? Don't you know about the word 'redundancy'? Don't you even consider that this faith in a company with an 800 number is....umm....naive?
Oddly Draconis
Too cynical to live, too stubborn to die.