Slashdot Mirror

← Back to Stories (view on slashdot.org)

Cisco Patches 'Black Hat' IOS Flaw

Posted by Zonk on from the spraypainted-white dept.

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

4 of 66 comments (clear)

  1. What ever happened... by Anonymous Coward · · Score: 5, Interesting

    So, what ever happened to Michael Lynn? He quit his job and made the presentation but, where is he today? Is he employed? Is he proud of what he did? Does he feel the price he paid was worth what he gave up for 15 minutes in the spot light? Would he recommend his "high road" choice to others in the future? Does he feel that he really made any difference in the end?

  2. The question is....... by 8127972 · · Score: 3, Interesting

    ..... Is this safe enough to deploy or should it be dropped into a test environment of some sort before deploying into a production environment? That assumes of course that admins have the luxury of delaying the deployment of this.

    --
    This is my opinion. To make sure you don't steal it, it's covered by the DMCA.
  3. Two scary bits" Completely Compromised by fuzzy12345 · · Score: 2, Interesting
    From TfineA:

    "In many cases, a heap-based overflow in Cisco IOS will simply corrupt system memory and trigger a system reload when detected by the "Check Heaps" process, which constantly monitors for such memory corruption."

    Is anyone else bothered that Cisco figures heap corruption is common enough that a process is running full time on production routers looking for it? I suppose you could view this as proactive, but obviously the process can only look for nonmalicious corruption, and is only statistically likely to find corruption before it causes errors according to how much CPU you give it.

    "In some cases it is possible to overwrite areas of system memory and execute arbitrary code from those locations. In the event of successful remote code execution, device integrity will have been completely compromised,"

    Think about it. Once an exploit is executed against your router, reloading your firmware isn't an option, because that's a function of your firmware, which could be corrupted. Unlike a computer OS virus, which can be circumvented by rebooting and taking control before the corrupted OS does, there's no way to preempt the corruption here. For total peace of mind, you'd either have to replace the (probably not socketed) flash chips, or take the whole unit out back and burn it. Am I wrong? Of course, that's not going to be Cisco's recommended solution.

    --

    Everybody's a libertarian 'till their neighbour's becomes a crack house.
    1. Re:Two scary bits" Completely Compromised by Anonymous Coward · · Score: 1, Interesting

      Cisco doing heap checking is a mark of a reasonable system doing checks on itself.

      It's a mark of a *bad* system. Why? Because 1) it means they believe they haven't properly written their software and, more importantly, 2) it doesn't guarantee you anything except "the heap was consistent up to 29 seconds ago". Who cares? I need the heap to be consistent *all* the time.

      The best thing is to just write the code correctly, the next best thing is to place some kind of "barrier" (at the hardware level? Who knows) between all memory access and the program that guarantees things are okay 100% percent of the time.

      It's like a DBMS without consistency checks, and when you point it out to the programmer, he writes a script that checks the consistency every 30 seconds. Well, what does it mean when the script reports an error? It means you might be totally screwed! It doesn't *solve* the problem.

      Cisco has shown that they aren't up to the task, so I'm not surprised, but don't fool yourself, this isn't "defense in depth" or anything like that. Defense in depth (to me) means, you have multiple layers, each capable *by itself* of defending the system. For instance, run your software in a chroot jail AND set resource limits so it can't open any files AND use a string library that's immune to buffer overflows. It doesn't mean, write some crap and then check it every 5 minutes with Tripwire.