FORCED RELEASE NOTES - CORE-090400 - BID 1634

[Vulnerability Help <vulnhelp () SECURITYFOCUS COM>]

-----BEGIN PGP SIGNED MESSAGE-----

As part of the VulnHelp policy:

http://www.securityfocus.com/archive/1/80167

The SecurityFocus Vulnerability Help Team is releasing details behind the
FORCED RELEASE of the CORE-SDI Advisory "UNIX locale format string
vulnerability".

Ivan Arce of CORE-SDI has already made an explanatory post to BUGTRAQ on
this issue. Hopefully this post can compliment that.

VENDOR CONTACT DATE: August 22, 2000

VENDORS CONTACTED:

Sun Microsystems - security-alert () sun com
Silicon Graphics - security-alert () sgi com, agent99 () sgi com
SCO -  security-alert () sco com,
IBM - security-alert () austin ibm com
HP -  security-alert () hp com
FreeBSD - security-officer () freebsd org
Debian -  security () debian org
Connectiva - security () conectiva com br
NetBSD - security-alert () netbsd org
RedHat -  security () redhat com
OpenBSD - deraadt () openbsd org
COMPAQ - rich.boren () compaq com
Mandrake - security () linux-mandrake com

FORCED RELEASE REASONING:

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.

CHRONOLOGY AND BACKGROUND

On August 22 CORE-SDI in conjunction with the SecurityFocus Vulnerability
Help Team mailed the above listed vendors with information on a
vulnerability in the Locale Subsystem. It was thought at the time that the
vulnerability was shared by several differant vendors. However, given some
preliminary testing by CORE-SDI it was found that Linux distribution's
glibc prevented the attack from happenning even though a number of
binaries were vulnerable to the attack in question. Nonetheless Linux
vendors were mailed in order to confirm that this was in fact true.

At roughly the same time several other independant sources were in contact
with the glibc development team and directly with vendors to notify them
that glibc contained a vulnerability which could be used in conjunction
with the same vulnerability which CORE-SDI had found in order to gain
root.

This series of events as best we can tell at the moment was as such:

1. Solar Designer <solar () false com> discovered this problem (or a subset
thereof) and mailed a developer of glibc in concerns to this vulnerability
on 2000/08/17.

2. Jouko Pynnvnen <jouko () solutions fi> August 27, 2000 finds a variant of
this vulnerability and noted this via the GNATS web based bug database for
glibc:

http://www-gnats.gnu.org:8080/cgi-bin/wwwgnats.pl/full/1870

Further, discussion was started on the Vendor Security List
vendor-sec () lst de .

3. "zenith parsec" <zenith_parsec () the-astronaut com> found a variant of
this bug and also published it to GNATS web based bug database for glibc
on Sep 2, 2000:

http://www-gnats.gnu.org:8080/cgi-bin/wwwgnats.pl/full/1883


NOTES

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.

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

Signed,

SecurityFocus Vulnerability Help Team

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>

iQEVAwUBObRLEF15pZzZvm7VAQE9tAgAgd7Y2FIv7O+nl6C0VEEqqpP8gm7waxm9
taQhrNrN9Tt/ubiqXnDSYaOlyP/gnr4NTuRYi08+fB3L7PDPLX2un1z2ljtjU9Wd
S2VrUBL/fkETagrOCWqNnEGBPnjo1ddY3o+8Fi6+mvKysrMCg0VGODNeiFcJOlXz
sN+d9YyNOkmJiDuL5azz3/7+x+IEdM94pxo8y7YSZYrCRG0u/dytH8bBvl8lPGUR
cDtU6CG5QdyfTtDa9+OfkMbifWsDiAfBsWTwUXYqGrLVAqW1rei7wmOM+F1IeVGm
tKo4TAGDCIR/JYGv2RNKwljcdcCPcWpWx6naFCg7sjWMm42QG9+PNA==
=zC/K
-----END PGP SIGNATURE-----