Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) In Defense Of Ascend...
On Wed, 18 Mar 1998 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.
Only if you do not care about security.
| 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...
This is simply not true. I can personally list many many vendors who
refuse to act on security related issues until they are brought out in a
very public full disclosure way. One very good example is a buffer
overflow allowing attackers to execute code on the stack of anyone running
a Windows version of Netscape 2.x. I disconvered the bug in Netscape 2.0
and immediatly reported it to Netscape by phone, fax, and e-mail.
Netscape did not get around to fixing this bug until the last beta version
of Communicator 4.0!
I discovered Ascend Kill I. I discovered the port 150 bug. Additionally
I reported this SNMP problem to Ascend in early 1996! It only took Ascend
2 years to address the SNMP issue.
Do the members of this list happen to remember how long it took Ascend to
make a fix for the first Ascend Kill?
I have many other examples like this.
| 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.
SNI has never posted to the Ascend mailing list. I do not have any
affiliation with SNI. I maintain rootshell.com. End of story.
| Why, Why, Why? It would appear that the only possible motivation
| is nothing more than self-interest and profits.
Or perhaps the security of the Internet.
| 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.
Wrong again. I wrote exploits for this bug in C, perl, and cape in an
effort to give everyone a chance to test for this vulnerability. SNI
never released an exploit for this bug. I recently have used cape and
thought it would be nice to include an example in cape since not many
people know about it. If you dislike cape, use Spak, or ipsend v2. Here
is a version for ipsend v2 written by Darren Reed :
(Oh no! I am promoting ipsend v2 now. What will I ever do?)
interface { ifname le0; mtu 1500; };
ipv4 {
src 1.1.1.1; dst 10.0.0.2;
udp { sport 9; dport 9; data { file ascend_data; }; };
};
send { via 10.0.0.1; };
| 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.
Not sure. Most hardware does not allow you to write to the unit and
DOWNLOAD the entire config, then allowing you to sniff the local ethernet.
| 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.
Many people cannot even set a telnet pw. Note that Cisco routers do not
have SNMP enabled by default nor do they allow you to telnet to their
routers if a telnet password is not set. If the telnet password is not
set then console access is the only way on.
| 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 does not even sell a product that guards against this type of attack.
SNI makes security auditing tools.
| 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.
No, it has forced Ascend into fixing a bug that they were previously
unwilling to fix.
| 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.
Have you ever tried to report something to CERT. CERT is a joke. Why do
you think lists such as Bugtraq and sites like Rootshell even exist?
| 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.
Not mention a fix. Filtering UDP port 9 was mentioned MANY times.
--
Kit Knox [kit@connectnet.com] - CONNECTnet INS, Inc.
++ 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: