Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) In Defense Of Ascend...
At 04:25 PM 3/18/98 -0000, tqbf@secnet.com wrote:
>Why didn't that happen here? Because we found it extremely difficult to
>find a contact at Ascend.
> Judging from this statement alone, I'd have to say you have set new
> bounds on incompetency. Ascend is a global company
It is unfortunate that representatives from Ascend have decided to make
this more of an issue, because the fact of the matter is that the balls
were dropped on their end, and discussion of this issue is only going to
highlight that fact. I really don't enjoy cluttering the mailing list with
this discussion, but when charges of "extortion" are leveraged against my
work, or when representatives of Ascend say that I am "incompetant", I
feel obliged to respond.
So, here it is in a nutshell:
Of all the vendors we have ever had to deal with in disclosing security
problems we've discovered, Ascend has been by far the most difficult to
deal with. Unequivocally.
When we find security problems, we contact the affected vendor and ask for
a security contact. A security contact is a person within an organization
who is responsible for dealing with reports of security issues with a
product. "Security contact" is not always a formal title; sometimes it's
just an added job duty thrown on an engineer. In larger companies,
security contacts are frequently dedicated to the task.
Typically, you can reach a security contact by sending mail to
"security@vendor.com". Some people might send actual security advisories,
detailing new problems found in a product, directly to this address. We
don't. We have no idea who is reading "security@vendor.com" mail, so
instead of sending details, we send a request for A.) the actual security
contact and B.) a PGP key.
When "security@vendor.com" doesn't work, we go to the company's website.
Sometimes, in the "CONTACTING THIS VENDOR" section of the website, there
is a security contact listed. Other times, we are forced to search their
website for keywords like "security contact" to find an address.
If that doesn't work, we call CERT. CERT is a globally recognized security
clearinghouse that has served the Internet since the Internet worm
occurred in the late 80s. Anyone familiar with computer security
recognizes CERT from their advisory publications, which summarize vendor
security problems and are widely disseminated. CERT maintains contacts for
many vendors; lack of a CERT contact means that the vendor likely does not
work with CERT to disseminate information about security problems.
When that fails, we call the company. When there isn't a prompt that says
"press 5 for the security contact", we talk to the operator and say "can
you please direct us to the security contact". We then explain what a
security contact is, because very few operators know.
We attempted to locate a security contact for Ascend Communications. We
mailed security@ascend.com and said "we have bugs, send us a contact". We
looked on their website. They had no listed security contact where we
could find it. We searched for "security contact" and got 3987498734 hits
talking about how their RADIUS server enhances network security. What we
did not get was a page that said "contact Joe Smith in engineering with
security problems."
We called the CERT coordination center to find a contact for Ascend. They
had no idea who to talk to at Ascend about security problems. They were
quite sympathetic to our plight, which was that we had security problems
that the affected vendor apparently did not want to hear.
We called Ascend Communications at 1-800-ASCEND-4. No voice prompt for a
security contact. We talked to the operator. I spent 5 minutes assuring
the operator I wasn't looking for physical/building security. I got pushed
around to other operators. Then I got shunted into front-line tech
support.
I left a message with tech-support and received a call-back about 2 hours
later. The person who called me was a support engineer. I explained the
problem in detail, using simple, descriptive words like "I can crash any
Ascend router on the Internet by sending malformed packets to UDP port 9".
The support engineer I spoke to made it sound like he was writing this
down. He then told me that he was going to hand the information to
engineering, and that I should mail support with more details.
I mailed support a uuencoded file containing the exact packet I sent to
crash the Ascend routers I tested. I received no response. At this point I
had an open trouble ticket at Ascend. Ascend had my electronic mail
address. Ascend had my phone number. Ascend had a ticket that should have
said "caller claims to be able to crash any Ascend router on the network."
I received no callback after that. Over the next month I repeatedly mailed
security@ascend.com, and we inquired with many people about finding a
security contact. Fully one month after contacting them, we gave up on
finding a security contact. Our feeling was that our attempt to contact
Ascend constituted a good-faith best-effort vendor contact, and that it
was important to get the information out.
Now, let's ponder this for a second. If I, an independant third party,
find a critical security problem in Ascend hardware, I have to go through
all of the above only to be told that my failure to SEARCH THE WEB FOR
ASCEND EXECS makes me incompetant (direct quote from Ascend!). Not only
that, but my actual productive effort to contact them is slandered by
Ascend --- because "calling support doesn't cut it". Does it sound like I
called tech support and left a message and gave up? I don't think so.
What does this tell us about using hardware and software from Ascend? It
tells us that people who find security problems in Ascend hardware and
software have absolutely ZERO incentive to contact Ascend before
publishing findings, because if they do so, Ascend will deride them and
Ascend customers will threaten lawsuit for extortion.
In other words, Ascend is providing every bit of incentive they can to
ensure that their customers will hear about critical security problems in
their products from USER MAILING LISTS, instead of from them, which means
that Ascend customers will be exposed to vulnerabilities during a window
of time when there is NO OFFICIAL ASCEND FIX.
Good policy, there.
Let us contrast this with our Livingston advisory. We contacted Livingston
and said "we have security problems, we want to talk to someone." We were
immediately provided with the email address of someone to talk to. That
person ACTUALLY TALKED TO US. We explained the problem, and we provided
them with a draft copy of our advisory to comment on. We helped them write
a fix, and pointed out other problems. The accepted all of our comments
graciously, and worked with us to coordinate a release date for the
advisory (our scheduled release date was during the Washington DC IETF
meeting, which was a problem for them).
Because of Livingston's approach to dealing with the issue, we were able
to tell the community about a serious security problem while ensuring that
fixes were available, the vulnerability confirmed at the vendor, and the
vendor was prepared to deal with the problem.
Livingston is not unique in this respect. We have had similar luck dealing
with Sun. We have had similar luck dealing with Microsoft. None of these
vendors tried to blame US for THEIR engineering mistakes.
I'll also note that NONE of the other vendors we have ever dealt with felt
the need to call us "incompetant", or to question our motives for
releasing security advisories (or accuse us of extortion). The accusations
being levelled at us are unique to Ascend Communications. More incentive
to deal closely with them, indeed.
Speaking of incentive to deal with Ascend: how many denial of service
attacks have Livingston, Cisco, Shiva, and USR had to contend with in the
past year? This isn't the first attack that will topple over arbitrary
Ascend routers; I recall being able to telnet to the remote management
port, hit "enter", and watch the box reboot.
How many router vendors ship SNMP "write" access enabled with a default
community? How many store the passwords to the box in plaintext in a
configuration that can be downloaded via SNMP write commands, enabled by
default and open to the world by default? Why does Ascend store the access
passwords to the box in plaintext? Cisco addressed this issue years ago by
storing hashes, not passwords.
Ascend equipment is showing itself to be insecure and unstable; it is
likely that MORE problems will be found in Ascend equipment as time goes
on. And yet Ascend makes it difficult to contact them with reports of
security problems. Why? Why can't someone simply mail security@ascend.com
and get an immediate response that says "we are concerned about these
problems, please contact so and so with details". Doesn't Ascend care
about security issues?
I'll wager the media exposure and the complaints they are receiving from
their users will cause Ascend to pay more attention to the manner they
deal with security problems. Perhaps now people will answer
"security@ascend.com" mail. That's good, since the next problem they deal
with may not be "crash Ascend routers" --- it may be "get remote access to
the management interface on Ascend routers without a password".
Hopefully, Ascend will learn from this experience that it is important to
make it easy for third parties to contact vendors about security problems.
It is not the responsibility of third parties to contact vendors at all;
it is Ascend's responsibility not to ship unacceptably insecure and
unstable equipment to unsuspecting customers. Thus, making it easy for
concerned third parties to assist Ascend with security is a good thing.
Hopefully, Ascend will also learn that deriding the efforts of these third
parties, questioning their motives, accusing them of extortion, and
berating them to the media does not provide incentive for these third
parties to help Ascend with security issues. If I was wondering what to do
with that new security problem I found with my Pipeline last week, I
sure know what I'm *NOT* going to do now, which is to give Ascend a chance
to shift the blame to me.
-----------------------------------------------------------------------------
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>