Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (ASCEND) In Defense Of Ascend...



In enteract.private.lists.ascend-users, you wrote:
>        Exactly.  No vendor, once aware of a security problem,
>        would do such a thing.  It simply makes no sense, even

This is blatantly untrue.

>        for a lazy vendor.  Conclusion?  Ascend was "made aware" 
>        (if at all) in only the most half-hearted manner,

This is untrue. Your "conclusion" is weak conjecture.

>        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

SNI had nothing to do with the distribution of the "Ascend Kill" program.
Kit Knox and ROOTSHELL.COM have absolutely no affiliation with our
organization. 

>                a) Why did they require Ascend to "reply" to get
>                   the full story on this problem?

We did not impose any such requirement; Ascend was informed completely of
the problem the day we discovered it, and every reasonable effort
(including repeated email, calls to CERT, etc) was made to contact them
after no response was obtained.

>                b) Why did they not send (gasp!) an e-mail, and 
>                   copy not only tech support, but also some 
>                   Ascend execs?  

Why WOULD we send a security advisory to Ascend execs? Why would a company
make it that difficult to contact them regarding security concerns?

>                c) Why did they not at least send a copy TO THIS LIST?  

Because, at the time, it was considered sensitive information. We are not
in the practice of releasing advisories to the public without a vendor
contact. Users of Ascend products are not vendor contacts.

>                d) Why did they send it everywhere else BUT this list? 
>                   They LATER posted a message to this list, defending 

This is blatantly untrue; I was personally responsible for distributing
the advisory, and this list was the first place I sent the advisory to.

>        Hmmm... how did rootshell get THIS paragraph, a blatant
>        sales pitch for "Ballista"?  Likely from SNI.  Smells like

You'd have to ask Kit Knox that. We are not ROOTSHELL.COM. We did not
write any of the exploits they provided (we have never, ever distributed
exploit scripts for the problem we find). We have no affiliation with
them. Likely, Kit Knox or the author of the exploits thought it was
courteous to plug our product, since we found the bug. We didn't ask him
to do so, and I'm not claiming that it's appropriate.

>        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.        

You are wrong about this. The problem with Ascend (and it is a problem,
and it is NOT a general problem with all routers) is twofold:

	A.) SNMP "write" is ENABLED BY DEFAULT with a WELL-KNOWN
 	    DEFAULT COMMUNITY.

	B.) SNMP "write" access allows an attacker to obtain the
	    PLAINTEXT PASSWORDS FOR THE BOX.

Can you do that on a Cisco?

>        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.        

>        SNI's actions amount to simple extortion.  At least Ascend,

You are suggesting that we are extorting from Ascend. That is absolutely
rediculous; the claims you're making aren't making Ascend look any better.

SNI has been responsible for no less than 25 OTHER security advisories,
detailing problems as severe or more severe than this one. Organizations
that have been directly impacted by our advisories include
Livingston/Lucent, Microsoft, Solaris, and Checkpoint. Not one of these
companies has brought legal action against us for "extortion", nor have
they publically decried our work. Perhaps you were unaware of this, and
figured this advisory was us singling out Ascend? 

You were wrong.

When we released our Livingston-relevant advisory, we were almost
immediately responded to by Livingston. We spoke with a developer at
Livingston and explained the problem. Because we were able to obtain a
contact there, we were able to coordinate the release of the advisory with
a fix, and the advisory was not released until Livingston gave a "go". 

Why didn't that happen here? Because we found it extremely difficult to
find a contact at 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 

This is just silly. The CAPE exploit (written by someone who does not work
for us) is identical in function to the "C" exploit. Do you verify facts
before you post them, and accuse companies of extortion?

>        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.

It is possible that my organization has more experience finding and
publishing security holes than any other organization on the planet. We
take responsible distribution of security information extremely seriously.
We deal with CERT, and with FIRST (do you know what FIRST is? And you
still feel qualified to discuss this?). We /always/ contact vendors prior
to releasing information. 

What we do not do is blindly send e-mail to CERT and to random addresses
at the vendor saying "look at this new hole that you have no patch for".
We call CERT to obtain a vendor contact (CERT has no Ascend vendor
contact). We call the vendor to locate their security contact and obtain a
PGP key for transmitting the information.

We were unable to do this, here, for reasons I have already explained.

>        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

Nice that you think that. We agree. We did not distribute, or have any
influence over the distribution of, the code you're talking about.

>        This was not a "security advisory", it was a sharp pointed
>        stick in the eye of anyone who owns an Ascend product. 

No, it was a security advisory.

I'm sorry to be this blunt with you, but here it is in a nutshell: you do
not know what you are talking about. You clearly don't have the facts to
back up any of your arguments, be they technical or political. You don't
know what was or wasn't done to contact Ascend; instead, you picked up on
someone who said Ascend wasn't contacted and decided to take that as
gospel truth. Your massive rant is both dishonest and irresponsible; you
are making things up to support your silly arguments.

SNI releases advisories for a few reasons:

	1.) SNI employees were all, to a one, active in discovering
	    and publishing security problems, in their spare time, 
	    before being employed by us. Many of the problems we take
	    knowing about for granted were discovered by SNI employees
	    prior to their employment here. Succintly: we enjoy and 
	    get professional satisfaction from finding new holes in 
	    software.

	2.) SNI believes that new security problems need to be distributed
	    to the community as quickly and completely as possible. This
	    stance is known as "full disclosure". It's a fundamental 
	    aspect of the way we function in the security community.

	3.) The discovery of new vulnerabilities strengthens our product.
	    Each problem we find is a new check we can add to Ballista, 
	    our network scanner. We think adding value to our products
	    while at the same time informing the community of security 
	    problems is an excellent way to finance security research.

If we wanted to profit optimally from our discoveries, we would not
publish security advisories. We would keep them secret and add checks for
them in our scanner, allowing our product to gain added value while not
allowing our competitors to add the same value. We don't have "proprietary
checks" in our scanner precisely because this is dishonest and unethical.

But, in any case, a parting thought:

Who cares what our motivations were? We found a security problem. It
exists because of the manner in which Ascend engineered their product.
Ascend users are vulnerable to the problem. It needs to be fixed. Why do
people feel that it is more important to talk about the reasons we
published the vulnerability, rather than dealing with the technical
problem of vulnerable routers?

-- 
-----------------------------------------------------------------------------
Thomas H. Ptacek			     		Secure Networks, Inc.
-----------------------------------------------------------------------------
http://www.enteract.com/~tqbf				"mmm... sacrilicious"
++ Ascend Users Mailing List ++
To unsubscribe:	send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd:	<http://www.nealis.net/ascend/faq>


Follow-Ups: References: