notice how their external customer-facing bug-tracking system usually removes all information, if visable/viewable at all. we should consider ourselves lucky that cisco even talks about what protocol this affects.

cisco sdlc surely needs work, but i’d rather that they “make nicer” with vulnerability reporting and information. cvss is a marketing checkbox for cisco, oracle, etc. what operators need is real information, and one normally only gets that in passing via the nanog, cisco-nsp, or nsp-sec mailing-lists. or through rigorous personal verification, which either involves reverse engineering against the IOS EULA or purchasing from ebay/graymarket.

cisco really works from the grotesquely outdated mainframe cathedral model of computing: load new code; reload; pray.

Regarding your comment on our “lack of clue”, the way Cisco described the DoS attack scenario is not dependent on the ability to execute arbitrary commands/code.

Of course you can take down service if you have arbitrary command execution. I think you’re missing the point. What they describe is an alternative method of disrupting service, namely “Repeated exploitation of the vulnerabilities could lead to an extended Denial of Service (DoS).” You have to ask, why would one need to repeatedly exploit the vulnerability in order to disrupt service? The answer, I presume, is that during the IOS reload, the service is unavailable. So if you repeatedly and indefinitely force IOS to reload, you’re causing a DoS without ever actually executing arbitrary code.

cvss is borken, and I mean BORKEN. this doesn’t even apply to people who do not have ftp configured… and it’s not a default. most people I know use scp, or possibly tftp over ipsec. sure, many enterprises still do unencrypted tftp – yet somehow this ftp vuln is worse than cleartext defaults that everyone has been doing for years.

as for remote code execution – yes, that means IOS, but if you’ve read Hacking Exposed Cisco Networks, you’ll know that it’s possible to run an IRC server or whatever you can dream up under IOS.

as for the denial-of-service, I am truly disappointed to hear veracode “lack of clue”… I mean, if remote code execution is possible then of course service could be taken down and resources could be used in any manner the attacker desires.