Where Does Truth Lie in Lynn/Cisco Case?

 
 
By Larry Seltzer  |  Posted 2005-08-01 Email Print this article Print
 
 
 
 
 
 
 

Opinion: Michael Lynn is an ambiguous hero at best. The information he revealed about flaws in Cisco's IOS needed to be disclosed at some point, but when and where was not his to say.

Theres general agreement among security researchers that disclosure of security vulnerabilities is a good thing. There isnt, however, agreement in the industry as to what full disclosure is and what the best practices are. Some say that immediate and complete disclosure of all details, including exploit code, is the best thing. I hope most people recognize that this would be an insane path to tread. Instead, vendors generally subscribe to an even more ambiguously named standard, responsible disclosure. Fuzzily put, this means that researchers disclose their findings to the vendor/author of the product and give them a chance to investigate and fix problems and distribute the fixes before disclosing the vulnerability.

But these arent the only valid concerns for a researcher, as was illustrated in the recent case of now-former Internet Security Systems researcher Michael Lynn in his Black Hat presentation last week, during which he discussed his ISS-funded research into flaws in Ciscos Internetwork Operating System. Contracts and confidentiality are important too, and all indications are that Lynn blew off his companys obligations. This was not his job to do, and whoever hires him next should know they cant trust him with confidential materials. If youve seen the presentation (Ciscos trying its best to clean it up, but its easily available) youll notice that he quit his job first, but then he went on to give a presentation with slides that had ISS copyright notices all over them. Is this purely legalism? I dont think so.

I got the presentation off the Full-Disclosure list, where the person who sent it declared the old and trite motto "information wants to be free." First, lets do away with the flowery metaphors: Information wants nothing. People want information to be free. Of course they do, especially if its valuable information. I want gasoline to be free too, but its harder to steal than information, so my cliches go unspoken.

Second, theres a difference between binding people to confidentiality agreements and censorship, and its somewhere near the difference between civil and criminal liability. If the government had ordered Black Hat and ISS and Lynn not to disclose the information, that would be censorship. There was some noise during all this about the FBI investigating Lynn; were he to be criminally prosecuted for disclosing this information that would be censorship. (Although consider the contemporaneous issue of the investigation of the leak of Valerie Plames name and status at the CIA; didnt that information "want to be free"?)

Lynn defends his decision to reveal details of the IOS flaw. Click here to read more.
Was there an attempt at responsible disclosure in the Lynn/Cisco case? Its hard to say, since there seems to be some obfuscation going on. I dont think Cisco is disclosing everything yet, even if, as we reported, they are disclosing a lot more than they had been. Cisco now discloses a vulnerability in IPv6 processing that could completely compromise a router. They list vulnerable and not vulnerable versions of their products.

As I understand the issue that Lynn discussed in his presentation, the real problem is not this specific vulnerability, which his presentation never actually refers to, but the fact that once you find such a vulnerability you can create a shell internally and execute what you want through it.

Lynn makes clear that conventional avenues of exploitation, like stack and heap overflows, are hard because Cisco is aware of them and goes to great lengths to avoid them. But its impossible to completely avoid them. Lynn is also clear that you can mitigate the problem by staying up to date on your IOS versions. This isnt because they fix the problem, just that newer versions make it harder to find and use known attack vectors, such as the IPv6 problem. Ciscos advisories dont really talk about the shell code problem, and they dont indicate that the "fixed" versions address it either.

So its hard to say whether either Cisco or Lynn violated responsible disclosure. The real issue is how long it has been since Cisco and Lynn understood the full import of the issue and whether they know if there has been any actual exploitation out there. We on the outside dont really know enough to judge this aspect of the situation until someone publishes a timeline.

Its also important to note that I dont actually know if any of Lynns claims are true. That Cisco is not directly denying them doesnt make them completely true, but it indicates that theres something to them and Cisco doesnt want to talk about it.

You may have noticed that Im talking about the same vulnerabilities I criticized Lynn for disclosing. This is part of that same distinction between censorship and confidentiality. I have no confidentiality agreement with Cisco, and the information is out there. Its possible to talk about it responsibly or otherwise. Its also responsible to ask if Cisco, after all that has happened, is serving their customers best interests at this point. If IOS has an architectural flaw that is not easily fixed, as many researchers now speculate, what can Cisco do to protect their customers?

Asking if Cisco is holding back on information, restricting myself to what I actually know and qualifying statements where necessary is, I hope, responsible and honest. Avoiding it would be like pretending Valerie Plame isnt really in the CIA.

Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983. Check out eWEEK.coms for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzers Weblog. More from Larry Seltzer
 
 
 
 
Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel