Bugtraq mailing list archives

Re: FORCED RELEASE NOTES - CORE-090400 - BID 1634


From: Jim Duncan <jnduncan () CISCO COM>
Date: Tue, 5 Sep 2000 00:58:44 -0400

Vulnerability Help writes:
The SecurityFocus Vulnerability Help Team is releasing details behind the
FORCED RELEASE of the CORE-SDI Advisory "UNIX locale format string
vulnerability".
[...]
The information on this vulnerability became available via several Linux
Vendor advisories. Given the nature of the bug CORE-SDI felt it was
important to post the advisory. The advisories in question were:

1. RedHat - glibc vulnerabilities in ld.so, locale and gettext
        http://www.securityfocus.com/advisories/2576

2. Debian - Glibc Vulnerability
        http://www.securityfocus.com/advisories/2578

Neither company responded to the original message, neither warned us to
the fact they were contacted by other people with information that
pertained to the same vulnerability, and they failed to warn us they were
going to release an advisory.
[...]
The net result here is that Linux vendors were aware this problem existed
in *other* non Linux UNIX distributions. In particular they were aware of
the fact that Solaris was vulnerable, yet advisories were released
regardless of this. It is a given that people who understand that the
Local Subsystem is cross platform (this is essentially anyone who reads
Bugtraq..) would realize that this problem would affect more than just
Linux distributions. As a result of no attempt to work amongst the Linux
vendors with other vendors a series of OS's are now unprotected to a very
serious, very wide spread bug.

That being said, there really is no one to blame for this situation. There
exists no forum for competing vendors to share information like this and
further many vendors simply don't seem interested in working with other
vendors to see multi vendor vulnerabiltities resolved.

That's not true; the FIRST maintains a method for competing vendors to
share sensitive information like this and to coordinate public
announcements regarding vulnerabilities.  There have been major events
in the past in which the Unix vendors that were members of FIRST at the
time (http://www.first.org/team-info/) were brought together by one of
the Unix vendors, advised of the vulnerability, worked out a schedule,
and then fixed the problem.  When they were ready, they published all
at the same time.

FIRST is often criticized, but it's better than nothing, and stating
that there is no such forum is decidedly counterproductive.  I have
recently begun trying to coordinate a similar venue for network
equipment manufacturers by encouraging their involvement in FIRST.  As
far as router makers go, the team I'm on, the Cisco Product Security
Incident Response Team, seems to be the only team of its kind.

It's likely that this type of incident will happen again.

Let's hope not.  This is outrageous, and shows a distinct lack of
maturity in the industry.  To earn the respect of the rest of the
world, we have to do better than this.  You can start by advocating
involvement in existing organizations that _do_ work, rather than
reconciling yourself to the opinion that it's hopeless.

Assume that mistakes _will_ happen; then what becomes important is how
you handle them.  Let's learn from this and prevent it in the future.

        Jim


--
Jim Duncan, Product Security Incident Manager, Cisco Systems, Inc.
<http://www.cisco.com/warp/public/707/sec_incident_response.shtml>
E-mail: <jnduncan () cisco com>  Phone(Direct/FAX): +1 919 392 6209


Current thread: