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@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@sun.com security-alert@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@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@remail.ecafe.org (ECafe Anonymous Remailer) To: cypherpunks@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?