Slashdot Mirror
Cisco Patches 'Black Hat' IOS Flaw
thursnick writes "eWeek is reporting that Cisco has finally issued a comprehensive fix for a critical IOS vulnerability that set off a firestorm of controversy at the Black Hat Briefings earlier this year. The patches come more than three months after former ISS researcher Michael Lynn quit his job to present the first-ever example of exploit shellcode in Cisco IOS (Internetwork Operating System), a presentation that landed him in legal hot water. Cisco's advisory effectively confirmed Lynn's summer warning that the flaw could be exploited by remote attackers to execute arbitrary commands or cause a denial-of-service on compromised routers."
So now we can all visit CiscoUpdate and have our routers automatically patched....?
Or do we have to manually evaluate lengthy decision diagrams, check memory requirements, prove that we have legally bought the affected hardware and software, and hope that the monolythic IOS image will not introduce bugs into other areas that are being patched by this fix?
If you read TFA, the bug involved system timers and how they were handled. Given that this probably affects most of the system functions, it's not surprising that it would take a while to make the changes and test it. Think about how long it took to fix the VM bugs in linux 2.4, this probably a change of similar magnitude.
"When you sit with a nice girl for two hours, it seems like two minutes. When you sit on a hot stove for two minutes, it
He's alive and well as far as I know. I saw him at Toorcon this year, but didn't speak to him.. (He was a speaker and gave a good talk on Reverse Engineering)
I know that he has a new job and I while I obviously can't speak for him, I got the impression that he felt as if he did his duty the security community. As an amateur member of that community, I'd thought that he put principle before pay and deserves our respect.
Simon.
It was not the first-ever example of exploit shellcode in IOS, Phenoelit already made public some Proof-of-Concept IOS exploits in the past. Phrack 60 #7
Mike is working at Juniper, and doing well (Juniper pays better than ISS, apparently, and their code is cleaner than Cisco's, plus they have some ethics). He feels he did the right thing. So do a lot of folks in the US military and intelligence communities, who are very very pissed off at Cisco for exposing them to a security risk of this magnitude and trying to cover it up. They consider Mike a hero, so he has some very useful new friends...
The answer is.....
/.) can add something to this thread.
This code has been out for a few months now, and many select beta sites have been testing it in production environments. The first few iterations had some serious (crash and reboot every few hours) problems, but it (12.2.15T1thru17) has been in production use on several edge routers for a month with no noticable problems. Cisco didn't just patch the one 'sploit published, they categorised the class of exploits and went about fixing many different possible attack vectors or watching for suspicious behaviour that could indicate a compromised system. That is what took several months even before Michael's talk, and its been in testing (and re-patching and recursion testing) since then. The announcement today is because they are confident their fix is solid, but anyone staying at the bleeding edge of IOS releases has been using it since at least June.
I'd say its solid, but I'm not rolling out the latest version on everything until others add some real world stress testing. I'm sure there will be several more newly introduced bugs uncovered in the new few months, and the timer checks usually result in a panic reload, not optimal for stable systems with SLAs and big money riding on them.
I'm also not in a rush to roll this out, because for the moment there are no known exploits running around. Maybe Effugas or some of the IOS engineers (I know you read
the AC
Hemos is like...sci-fi fans;he thinks technology is cool, but he hasn't bothered to understand the science it's based on
Cisco doing heap checking is a mark of a reasonable system doing checks on itself. Why is this bad? They almost never use the stack, so they check the memory they are using a lot. It doesn't run often (Lynn found it running about once every 30 seconds or so), and it's a good thing to do. Why complain?
As for reloading firmware, I don't think you understand Cisco stuff. There is a mini-firmware burned into ROM on all the Routers & Switches...it's called ROMMON mode on the ones that immediately come to mind. If your device firmware is totally thrashed (by a worm, by some damn fool tftp'ing up an image for the wrong router type, etc) you'd just use ROMMON mode to re-load a good image. Now, the real problem is that a worm could trash your flash storage.
In that case, unless you've got one of the expensive boxes with removable flash cards, you've now got a very expensive paperweight.
You aren't vulnerable. The bug was integrated in 12.4(2)T1, so you already have the fix. Older 12.4T versions will be vulnerable, such as 12.4(2)T.
thats funny; it never fails to amaze how many people can't be bothered to read the actual body of an article before commenting on it...
I'm Michael Lynn, so I know a thing or two about what went on...I DID NOT release any bug details, I DID work with the vendor, the bug in question was patched months before I went on stage as a result of my working with PSIRT, and when I went on stage I didn't disclose any details about any bug...all I did was prove it was possible to exploit bugs on IOS...
If you don't believe me, then go and find out the exact nature of the vulnerability...you won't be able to do it (at least not without disassembling the thing yourself and rediscovering it) because I never disclosed it to the public...furthermore I disclosed it to the vendor months in advance, waited for them to get a fix out, worked with them all the way until about 48 hours before the talk...they were even going to co-present with me, then someone changed their mind and went into panic mode...
--Michael Lynn