Researcher Resigns Over New Cisco Router Flaw 423
An anonymous reader writes "Michael Lynn, formerly a researcher for Internet Security Systems resigned today rather than conceal his research into serious new flaws in Cisco routers, according to stories at Washingtonpost.com and CRN.
Interestingly, Cisco says the the problem is not a security vulnerability, although it chided Lynn for not going through proper vulnerability disclosure channels. Both stories note that Lynn is in danger of being sued by Cisco for revealing the information, details of which were pulled at the last minute from the materials handed out to Black Hat attendees." Update: 07/28 12:23 GMT by Z : SimilarityEngine writes "Cisco and ISS are filing a law suit against Michael Lynn and the management of the Black Hat Conference, following Lynn's presentation discussing a vulnerability in IOS."
Re:Cisco has gone downhill recently (Score:5, Informative)
That was from a while back. They had set up a master "backdoor" password in a version of IOS and ended up getting ridiculed for it quite heavily.
Re:I wonder... (Score:4, Informative)
not applicable... (Score:2, Informative)
you could get protection if you come out and reveal your employer is a racist who told you he refuses to comply with the law and hire blacks, or fired women who got pregnant rather than give them the benifits the law requires.
i think this guy might go to jail for what he did.
Lynn is in danger of being sued by Cisco for revealing the information, details of which were pulled at the last minute from the materials handed out to Black Hat attendees
of all the places to reveal the information, why give it to black hats? it is like going to a criminal convention and telling them how to turn off security cameras at one bank chain.
if someone used the information he handed out, this guy should be locked up because he will be directly responsible for the damage that is caused.
They Had Been Working on it for *4 Months*! (Score:5, Informative)
http://blogs.washingtonpost.com/securityfix/2005/
The injunctions filed against him state that ISS and Cisco had been working together on the flaw for the past four months, and that up until earlier this week, a Cisco executive was slated to co-present the findings with Lynn at Black Hat.
Contact for Cisco's Point man on this (Score:3, Informative)
If you'd like to write to Mojgan and say that you don't like their attitude toward full disclosure, or their attack on the guy who's working hard to make things secure, here is his information.
If nothing else, you could ask him "what law did the guy break, biatch!?!"
Mojgan Khalili
Cisco Systems, Inc.
978-936-1297
mkhalili@cisco.com
Re:not applicable... (Score:3, Informative)
Re:Cisco themselves said it was not a new flaw (Score:3, Informative)
He may have misused information from his former job at ISS and be operating outside the bounds of his ISS employee contract allowed him to act.
*: I can see how, if the source codes contain hash numbers which are generated elsewhere and need cracking, that there would be reverse-engineering the source code. If it was recovering the source code from a compiled binary, why not say so? If breaking the DMCA by decompiling an encrypted binary, why not tell us?
Re:Good.... (Score:4, Informative)
Re:This could have been avoided by using apt-get (Score:2, Informative)
What do you think a Cisco router is? Traditionally, an underpowered general purpose CPU running a somewhat-specialized operating system.
Unless you're talking about the "big boys" (Catalyst switches, Cisco 10000s, etc) switching is not done in hardware.
He TOLD THEM BACK IN APRIL (Score:1, Informative)
Except Cisco were told back in April. What they did was fix this particular buffer overflow without tackling the method used to run the code. This was what incensed him so much, they half fixed it, enough to get by with for today.
So yes, they had already had their warning and chosen to ignore it.
Re:I wonder... (Score:3, Informative)
"The injunctions filed against him state that ISS and Cisco had been working together on the flaw for the past four months"
Four months qualifies as a "few weeks" in my mind.Re:I wonder... (Score:3, Informative)
Exactly. IIRC from another article this morning, the flaw was disclosed a while ago, I think in April. He publicly announced it on Wednesday July 27th. That's indeed around 3 months.
Using any buffer overflow or similar flaw, he showed how you could take control of the IOS (the OS on the router?). The IOS is supposed to be abstracted from the hardware and immune to this type of flaw.. this wasn't supposed to be possible before. So this flaw isn't tied to a specific low-level buffer-exploit vulnerabilty, so it's not enough to patch that vulnerabilty, because as soon as another is discovered, the IOS will be vulnerable too.
From other posts, it seems Cisco is usually quite reactive to flaw disclosure. Maybe this flaw was bigger and tougher to fix than the usual, but according to a Wired article [wired.com]. CISCO wanted to keep the flaw secret until next year, when a patched IOS beta would be released.
Lynn found this outrageous.
Outrageous enough to quit his job on the spot, burn himself from the industry's eye, and expose himself to a lawsuit from Cisco. Doesn't that make you think?
Re:Why? (Score:3, Informative)
Long enough to make sure the fix works without breaking some other function. Or would you prefer that they release the updates without making sure that something important - like, say, BGP updates - still works? That'd be *real* smart.
I, personally, would prefer that Cisco makes sure that they haven't added new unintended features to IOS before they release new code.
Since... (Score:3, Informative)
There are various protocols that are directly used by VoIP - these would include things like SIP, UDP connections for the streamed audio and other fairly mundane stuff. For videoconferencing (a related technology), you'd probably use IGMP to set up the multicast conference.
Of these, IGMPv3 (the newest version of IGMP) is the only one the router would really need to talk. It is also a variable-length structure, which means crappy implementations may be subject to buffer overflow. On a liklihood scale of 0-10, where 0 is impossible and 10 is a certainly, I'd put this at a 2 or 3.
There are also indirect protocols used with VoIP. Most VoIP setups that want any decent quality will use bandwidth management schemes, such as QoS. Cisco routers support a number of QoS functions. Some are local, but IIRC, some will propogate between Cisco routers. It could be there is something exploitable in such a mechanism. On the same scale as before, I'd put this at a 4, as I doubt the QoS code has been as extensively tested by consumers or by crackers.
A third option is that it is only tangental to VoIP. The easiest way to secure VoIP is to set up IPSec tunnels. Could there be a flaw in IPSec that can be exploited? There are two candidate areas here - one would be a flaw that made it possible to spoof legit connections without the Cisco router being able to tell. The second, and more serious for Cisco, would be if there's a bug in IKE/ISAKMP where a malformed and/or oversized packet did Really Nasty Things.
Again, IPSec isn't widely deployed so the bulk of the testing it will have received will have been from Cisco itself and not from users (who are always much more creative in creating bizare network scenarios). Of all of the options I've outlined, it would also be the strongest candidate for a follow-on discussion after talking about the security of Internet Telephony. It is also the most complex, in terms of packet exchanges, putting it at a higher risk of having bugs. Again, on the scale I gave, I'll put this at a 6.
Finally, a lot of router technology (not just Cisco's products) are open to ARP cache poisoning, router table poisoning and the like. In a VoIP scenario, these could be used to redirect a call as a means of wiretapping it without duplicating it. This would fall in the category of VoIP security and router security. Normally, routers are set up so that they can't get routing information from anyone. However, one place I worked, I did see a fairly major ISP fry three of its routers with circular routes.
It is possible, then, that Cisco's handling of router-level traffic is suspect - perhaps there's a buffer overflow somewhere that allows escalated priviledges to another networked device. The problem here is that this IS in an area that has been extensively used and tested in the field by Joe Average Customer. And if Joe Average Customer cam crew up, they will screw up.
Knowledge of such a bug would not be kept under wraps, simply because too many people would be experiencing it first-hand. (Same reason Windows bugs aren't secret for long.) So although this is a well-known problem with networks, I would say that the chances of this being the bug Cisco is fighting tooth-and-claw with is about a 2.
The only way we'll know if I'm even remotely close, though, is if Cisco or the researcher says something definite. Either that, or some Black Hat skilled in the Dark Electronic Arts reverse-engineers the defect from what has been said and publishes their observations.
Re:I wonder... (Score:5, Informative)
Re:Whose rights were violated again? Hmm? (Score:2, Informative)
Last time I looked, there is no such thing as "intellectual property rights". There is copyright law, patent law, and trademark law. These three are commonly grouped as "intellectual property" in the media, but that phrase has no legal standing.
As far as I can tell, no Cisco copyright was violated; no patents were infringed; and no trademarks were fraudulently used. Thus nothing illegal has occurred.
The only remaining possibility in the U.S. is a violation of the DMCA, which Cisco hasn't mentioned. The DMCA is pretty complex, but as far as I can see, the only way it would apply here is if Cisco had encrypted their information and Lynn had decrypted it for commercial purposes. I don't know if compiling source code to object code counts as encryption for the DMCA, and the purposes of the "decryption" are a fair stretch in that context anyway. So I don't see that as being a legal problem here either.
Re:I wonder... (Score:3, Informative)
Re:I wonder... (Score:4, Informative)
He used an already patched exploit to show the vuln. He only showed how easy it would be were you to find a new, unpatched exploit.
Also, from an interview at security focus [securityfocus.com]
"It has been confirmed that bad people are working on this (compromising IOS). The right thing to do here is to make sure that everyone knows that it's vulnerable."
The bad guys already know about this, Lynn believes it's time the rest of us found out.
It's not a law suit... (Score:2, Informative)
Re:I wonder... (Score:3, Informative)
Please try to stay with the group.
Don't be an ass, turnstyle had a legitimate point. This used to be a problem that a "small number" of black hats could exploit, now it's a problem that a million script kiddies know about. Now don't get me wrong, I'm not trying to claim that cisco was fixing the issue promptly enough, but dissmissing people who point out the problems with full disclosure is just plain irresponsible.
Much ado about nothing? (Score:2, Informative)
It's pretty much accepted across the industry that the disclosure that there is a vulnerability is a "good thing". Indiscriminately revealing the gory details about how to exploit the vulnerability is a "bad thing".
After reading all the articles, it sounds like the exploit was discovered months ago, the patch has been available for months, and though Mr. Lynn demonstrated that the exploit is real (usually required to establish credibility) he did not expose the gory details necessary to allow someone to exploit the attack on their own.
So what's the big deal?
I'm particularly annoyed with Cisco's comment about Mr. Lynn having "illegally" obtained his information. Frankly, it's in the best interest of the public, the Internet, and the security world that security researches will decompile code to search for exploits. The security indsutry accepts that "security through obscurity" is a very bad idea. Vetted code is deemed secure because the gory details have been explosed to a wide audience and *still* no exploits could be found -- NOT because nobody was allowed to know how it all worked.
Re:Contact for Cisco's Point man on this (Score:0, Informative)
Khalili, Mojgan
781-788-9222 (Anywho.com listing)
http://maps.google.com/maps?q=13+Highland+St,+WES
Link to location of residence.
Got to love public information...
Re:I wonder... (Score:3, Informative)
what it was (Score:1, Informative)
http://www.angelfire.com/ego2/hellomother/BH_US_0
Cisco settles! (Score:3, Informative)
I'm glad for Michael Lynn that this affair ended quickly and not too harshly. Kudos to him for his courage.