Sir, I know not who you are, being a fresher to this list... But execellent stuff. Look forward to more in the future. I have found Ascend to be more than helpful (Europe tech Supp) and their code to be markedly better than some others in the industry: MaxiProfit Windows, 2+1Com, Grey Horse to misname but a few. The above is IMHO and noway reflect the views of my employer or their subsiduaries! IanC -- +------------------------------------------------------------------+ | Ian Cowley Network Design Consultant | | mailto:icowley@lsil.com or mailto:yelwoci@compuserve.com | | WWW http://ourworld.compuserve.com/homepages/yelwoci | | | | LSI Logic Europe Ltd Tel: +44-1344-413234 | | Greenwood House, London Road, Fax: +44-1344-413114 | | Bracknell, Berkshire RG12 2UB http://www.lsilogic.com/ | +------------------------------------------------------------------+
-- BEGIN included message
- To: ascend-users@bungi.com
- Subject: (ASCEND) In Defense Of Ascend...
- From: throwaway-id@technologist.com
- Date: Wed, 18 Mar 1998 08:46:31 -0500 (EST)
- >Received: from max.bungi.com (max.bungi.com [207.126.97.7]) by mail2.lsil.com with ESMTP id HAA19790 (8.6.12/IDA-1.6); Wed, 18 Mar 1998 07:42:47 -0800
- Sender: owner-ascend-users@max.bungi.com
Come on, people! Ascend deserves to be beaten about the head with a 2x4 on a number of issues (and the members of this list do a good job of it), but the issue of this specific security vulnerability does NOT seem to be one of them. Jason Nealis wondered: >This is amazing, Why in the hell would they sit on it. Exactly. No vendor, once aware of a security problem, would do such a thing. It simply makes no sense, even for a lazy vendor. Conclusion? Ascend was "made aware" (if at all) in only the most half-hearted manner, deliberately intended to NOT produce action or reply. Why? "De omnibus est debitandum!" ("Everything should be questioned" - [Descartes]) Read on... From the news.com article: >"Huger said Ascend was advised of the problems with its equipment on >February 4, but once Secure Networks did not hear a response, the firm >disseminated a security advisory to various groups on the Net. " Oh, so SECURE NETWORKS (a for profit company with its own products to sell) just decided to "disseminate" not only an advisory, but a complete "Do-It-Yourself Max/Pipe/TNT Killer Kit" to every wannabe cracker and pre-teen vandal on the net! Why? Because their feelings were hurt when Ascend did not reply in a timely manner? Bull. a) Why did they require Ascend to "reply" to get the full story on this problem? b) Why did they not send (gasp!) an e-mail, and copy not only tech support, but also some Ascend execs? c) Why did they not at least send a copy TO THIS LIST? d) Why did they send it everywhere else BUT this list? They LATER posted a message to this list, defending their actions, and thus proved to all that they knew that this list existed. Why, Why, Why? It would appear that the only possible motivation is nothing more than self-interest and profits. From the rootshell e-mail: >Secure Networks makes security auditing software called Ballista. It has >its own scripting language called cape. Here is a version of Ascend Kill II >written in cape. Check out how small it is! Hmmm... how did rootshell get THIS paragraph, a blatant sales pitch for "Ballista"? Likely from SNI. Smells like self-promotion to me, which seems a bad thing to mix in with a security advisory. Jennifer Dawn Myers, Ph.D. of Secure Networks stated: >At issue is that an Ascend's entire configuration, including all >passwords in _cleartext_, can be had if the write community is >guessed. If the SNMP write community is guessed for ANY device, the guesser can wreck all sorts of havoc with that device. No startling news here. >For many boxes, this guess will be easy, as they won't have >been configured away from the default write community of "write". Cars are also sold with the doors unlocked, so the buyer can get into it and drive it away! The BUYER is responsible for locking the doors! Anyone who wants to critique Ascend's position on this point is being silly, since the initial configuration of an Ascend product is only slightly less complicated than landing a Tomcat on the deck of a carrier under storm conditions! Setting an SNMP community string is the ONE thing that should be familiar to anyone who is worth their pay. >(That document also urges people who are concerned about security to >change the defaults). But what it does NOT do is suggest that the reader run out and buy products from SNI, which may have been the only way to prevent SNI from ambushing Ascend on this issue. As an aside, this is the first person I have seen who has posted to the list and included their academic degree in their .sig. This practice is most often a good indicator of either an "academic", and/or a person who feels that they need the label to add credibility to otherwise unsupportable statements. A Ph.D.? Big deal. I have two Ph.D.s, (yes, that's right - I'm a paradox!) but they make me no better than anyone else on this list. (Well, perhaps better read). We are all equals here, which is why the list works. SNI's actions amount to simple extortion. At least Ascend, if not some of Ascend's customers, must now buy a copy of the SNI product to test the "cape" version of the code, and insure that the "fix" is a real fix. By "disseminating" the information to multiple mailing lists and newsgroups, SNI has promoted itself and its products at the expense of Ascend, and Ascend's customers. Likely, the item will be forwarded to the media by Ascend's competitors and/or SNI itself. This will further promote SNI and their products at the expense of Ascend and their customers. (One of the lousy things about being "on top" is that there is only room for one at a time...) What would have been the responsible thing to do when finding this "security hole"? What would have YOU done? You would have sent Ascend and CERT an e-mail outlining the entire problem. Such an e-mail would have not required either group to "call you back" to get the complete scoop. While "public" announcement of security holes (and their fixes) is good practice, it is very nasty to distribute the code required to "break" a specific device, and not even mention the possibility of a fix. It creates a "window of opportunity" for the very people one would NOT like to have such code, and one can be assured that the wannabe crackers are the most enthusiastic readers of the security newsgroups and lists. This was not a "security advisory", it was a sharp pointed stick in the eye of anyone who owns an Ascend product. If I were Ascend's legal counsel, I would contact my local prosecutor and suggest prosecution of SNI for attempted extortion of Ascend and all Ascend customers. If Ascend found that SNI had used similar practices in other cases with other vendors, I would allege RICO, since the practices would indicate an "a pattern of criminal activity by an organized group". The combination of a class-action civil suit and a criminal prosecution ought to catch SNI's attention! At the very least, SNI's actions were irresponsible in the extreme. These actions are especially irresponsible for a company in the security business, who has no excuse for not "knowing the drill". Jason Nealis continued: >This really amazes me, I remember the last time something like this >happened, It took forever to get a fix. Then one should be satisfied with Matt Holdredge's responses on this point, in that it shows IMPROVEMENT over last time. (Hey, the 2x4s worked, guys and gals! Order more lumber!) >Please explain to me why you would use anything on the discard port. This IS a good question for Ascend. Why would anyone design a "magic packet" into both the RAS and the management tool that, when sent to the TCP/IP equivalent of /dev/null, bounces the machine? Is this function not better accomplished with a legitimate (and documented) SNMP writable "reset button"? Seems to me like someone at Ascend was not thinking clearly at all when they thought up that one. If the "discard port" is like a trashcan, then the "magic packet" is a malatov cocktail that burns the contents of the trashcan, along with everything for a 1000-foot radius! (The actual impact on one's Radius server seems to be a non-issue, but I digress...) Come on, Ascend, I will stand behind you when you are done wrong, but it is Ascend's job to avoid the deliberate design of somewhat obvious security holes. To think that people paid MONEY for this sort of fuzzy thinking! (Sorry for the bogus return address, but long-term readers of this list may recognize the style, and thereby know who the author is. I am not stupid enough to taunt people who work with network security, and have the level of ethics demonstrated by the group at issue. Post replies to the list, since by the time you read this, the account from which it was sent will be no more than a memory.) ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request@bungi.com To get FAQ'd: <http://www.nealis.net/ascend/faq>
-- END included message