Sun patch pulled

Sat Mar 30 00:03:50 PST 1996

Folks,

I am the person responsible at Sun for coordinating security-related patches.
I got several copies of Wednesday's message about Sun's syslog/libc patches.

There are plenty of disasters we can blame on ITAR, but the statement

 > Yup, that's right.  The syslog hole that was so well publicized by
 > CERT will remain open indefinitely because the ITAR makes it illegal
 > for Sun to distribute the fix!

is in fact 100% incorrect. I know; I was personally involved at every stage.

I'm afraid the detailed explanation which follows is necessarily stultifying.
But the key points are:

1. Our syslog patches (and in fact all of our security-related patches) are
available to anyone who wants them, anywhere in the world, whether they are a
Sun customer or not and whether they have a support contract or not. This
has been Sun's policy since about 1990, and it hasn't changed.

2. We did make a change in February--it seems fairly routine to me, but you
be the judge--but we weren't prodded by any government figure. We were just
making sure that we complied with the letter of the law. That's no fun either,
but it's a far cry from "gummint dweeb[s] whispering threats".

3. We didn't document the change very well, which surely contributed to the
confusion. I expect we will update the README files to try to explain this
better.

OK, now before I lose you in the morass of detail that follows, please note
this. Sun maintains an alias, "security-alert at sun.com", for questions about
security issues, especially as they relate to patches and fixes. I'm the person
who tends it (I got about 2,000 inquiries last year) and I will be glad to
answer any questions like this in the future. (Please send them to the alias,
not to me: it's got backup coverage and my personal e-mail doesn't).

If this inquiry had gone to any of our Solution Centers, they would have come
up with this answer, too, by the way. All right, Here We Go...

SYSLOG/LIBC PATCHES

Here is the list of patches currently available for libc to patch the syslog
vulnerability. Note that, for some versions, there are both "U.S." and
"international" versions. This distinction is the source of the confusion.
I'll explain it later.

        PATCH #     VERSION                 RELEASED
        ---------   -----------             ------------
        100891-13 - SunOS 4.1.3             Oct 27, 1995 (International)
        101558-07 - SunOS 4.1.3_U1          Oct 27, 1995 (International)
        102545-04 - SunOS 4.1.4             Nov 16, 1995 (International)
        100890-13 - SunOS 4.1.3             Feb 21, 1996 (US only)
        101759-04 - SunOS 4.1.3_U1          Feb 21, 1996 (US only)
        102544-04 - SunOS 4.1.4             Feb 21, 1996 (US only)

        102903-01 - Solaris 2.3             Nov  2, 1995
        101945-36 - Solaris 2.4             Jan 11, 1996
        102905-01 - Solaris 2.4_x86         Nov  2, 1995

Notes:

1. The patches shown for 4.1.3 also apply to 4.1.3c.

2. Solaris 2.x (SunOS 5.x) systems are internationalized, so there's no
distinction between "US-only" and "International" versions. To completely close
the syslog family of attacks, you will need to install recent versions of the
jumbo kernel patches (not shown) also.

3. No patches are necessary for SunOS 5.5 (Solaris 2.5) and later. The fixes
made the release.

"US-ONLY" VS. "INTERNATIONAL" VERSIONS OF THE C LIBRARY

In SunOS 4.1.x (the BSD-based Unix), Sun maintained two separate versions of the
C library. The so-called "domestic" version contained DES-based crypto routines,
accessible via a public API. Since we interpreted ITAR to outlaw the exportation
of such a library, we modified our build procedures to produce a less capable
version which we could legally export. All this time, then, we have maintained
two separate sets of patches, one which could legally be exported and one which
could not. (I'm not going to get into details about the technical differences
between the two.)

With the advent of SunOS 5.x, we introduced new methods of handling both libraries
and patches, and this problem went away. That's why there is only one version of the
C library for each version of the OS.

for many years, we called the library version which contain the forbidden-to-export
stuff the "domestic" version, and the other the "international" version. When we
made the latest change (described in the next section), we changed the wording from
"domestic" to "U.S.-only". After all, the word "domestic" applies to every country
from a certain point of view, doesn't it?

The nomenclature is still not quite right. Here is an attempt at a precise statement.
If your SunOS 4.1.x system has the "crypto kit", you can and should use the version
of the C library dubbed "U.S.-only". If your system is not using the "crypto kit"
--whether or not you or it resides in the U.S.--you can and should be running the
"international" version. The crypto kit costs extra, so if you're not sure, you're
probably running the "international" version. Most of our customers are.

The folks at your local Solution Center can probably explain this better than I can.
I encourage you to contact them for more details on this part, or help in determining
which software you are running.

WHAT CHANGED IN FEBRUARY

The change we made in February was to stop the practice of making the "U.S.-only"
version freely available through our world-wide patch database. It is, after all,
"world-wide"; so, after one of our periodic reviews of patch practices the responsible
manager made the policy change. We removed the library code from the latest versions
of the 4.1.x patches, and updated the README files to explain the change.

I don't know for certain whether this was in response to any particular warning
from the U.S. government. I'm assured by the person who made the decision that it
wasn't.

Anyway, the only impact of this change on our customers is that 4.1.x customers who
do have the "crypto kit" installed on their systems now have to go through the Solution
Centers to get C library patches. (I guess a second impact is that folks who aren't
licensed to have the crypto kit can't get the "U.S.-only" library version--but
they're not entitled to have it, and in theory couldn't make use of it anyway.)

I can understand why the original poster found this difficult to figure out by
him- (or her-) self, I guess. Anyway, the README file does say, right near the top,

        Please contact your Sun Solution Center or other SunSoft
        authorized service provider (ASP) in the U.S. to obtain a
        copy of the actual patch.

... and that's what several of our affected customers have done, since.

We certainly apologize for any confusion.

-mg-

Mark Graff
Sun Security Coordinator
mark.graff at sun.com
security-alert at sun.com

p.s. I'll include this explanation in my next Sun Security Bulletin. (If you want
a free subscription, BTW, just send a message to security-alert at sun.com with the
subject "SUBSCRIBE CWS your-mail-address".

p.p.s (If anyone wants to discuss this further with me, please pursue it
privately. I didn't pop my head up over the parapet to get drawn into a big
public ITAR debate.)

 From: cpunk at remail.ecafe.org (ECafe Anonymous Remailer)
 To: cypherpunks at toad.com
 Subject: Sun patch pulled (was Re: HP & Export of DCE)
 Date: Wed, 27 Mar 1996 23:16:56 GMT

 I noticed that Sun's latest libc patch (101759-04) is empty.  Previous
 versions contained the complete U.S. version of libc, including the
 tres-dangerous DES and crypt functions.  In the current rev only the
 README remains, presumably because:
         EXPORT INFORMATION: This patch includes code which performs
         cryptographic functions, which are subject to U.S. export
         control, and must not be exported outside the U.S. without
         prior approval of the U.S. government.  Prior export approval
         must be obtained by the user of this patch.

 So, you might ask, what fixes is Sun not distributing???
     (Rev 04)
         1190985 gethostbyname() can trash an existing open file descriptor.
         1182835 portmapper silently fails with version mismatch by PC-NFS
                 client
         1219835 Syslog(3) can be abused to gain root access on 4.X systems.

 Yup, that's right.  The syslog hole that was so well publicized by
 CERT will remain open indefinitely because the ITAR makes it illegal
 for Sun to distribute the fix!

 So did HP and Sun spontaneously, simultaneously develop crypto awareness,
 or is some gummint dweeb whispering threats in their ear?