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.
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.