Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) In Defense Of Ascend... Virus anyone?
This sorta relates back to the days when we were told the
same people writing viruses and spreading them across the BBS's/Inet
were also making big bucks selling their Anti-Virus software.
throwaway-id@technologist.com wrote:
> 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>
-- Tim Connolly tec@mountain.net MountainNet, Inc.
-- (304) 594-9075 ext. 37 2816 Cranberry Square
-- fax (304) 594-9088 Morgantown, WV 26505
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>
References: