Linux in the news
All in one big page
See also: last week's Security page.
News and Editorials
Fast response versus vendor coordination. Leading the new security reports section, you'll see a complex report on glibc problems and updates this week and last. One of the problems in glibc that was reported and fixed was a format string vulnerability in locale. This was demonstrably locally exploitable to gain root access. From a Linux-centric perspective, the process for fixing this moved forward in a fast and straightforward manner. However, there was another side to the story.
Simultaneous to the glibc locale discovery, CORE SDI discovered and reported a format string vulnerability in the Unix locale subsystem. They reported the discovery to SecurityFocus' vulnhelp forum, a forum set up to provide access to expert assistance in both verifying problems and in contacting vendors in advance, so that fixes for the problem could be readied. Particularly in this case, the problem affected so many different Unix and Linux operating systems, and no good workaround was available, so it was felt to be essential to work with the vendors. CORE SDI and SecurityFocus contacted a long list of vendors, including the many various Linux distributions. They were surprised, and strongly displeased, when several of the distributions did not respond to them, yet chose to publish the vulnerability, with updates, even though other vendors had not had the opportunity to develop fixes for the problem.
This issue is not new. CERT has long been known for the effort it puts into coordinating with vendors before releasing advisories. Correspondingly, they are also famous for advisories that come out months after the initial report of a problem, frequently after the problem has been widely exploited. Some vendors, for some problems, will be able to get fixes out very quickly. Other vendors, or other problems, may be more difficult to get out. Experience has shown that nothing irritates a vendor more, or motivates them more, than publicity, particularly publicity showing faster response from another vendor. Contacting other vendors that are potentially impacted before publication is a "good thing". Deciding how long to wait, if at all, before publishing your own fixes is a tougher decision.
Were the Linux distribution vendors at fault in their release of their updates? There will never be a unified opinion on that. Obviously, CORE SDI and SecurityFocus feel that they should have held their updates back. If they had done so, though, they would certainly have come under fire from others for slow response to a known, potentially severe security vulnerability. After beating on Linux distributors to get fixes out in a timely manner many times in this forum, for example, we are hard put to say that they made the wrong choice.
However, by operating in a very Linux-centric manner, and particularly by not communicating back with CORE SDI and SecurityFocus in a timely manner, they were certainly impolite. Such impoliteness can undermine potential future cooperation and should definitely be avoided. Even if they chose to go ahead with their advisories and updates, working with and notifying other interested parties in advance is a worthwhile choice.
In some respects, we may be viewing the effects of a lingering Unix vs Linux split. Many people in the Linux felt (and were) ignored by the Unix community in the early years of Linux (1993-1998). As a result, a habit of non-communication has grown up. If this is indeed part of the root of the problem, its eradication will come from the efforts of individuals on both sides to become more aware of the concerns and work of their counterparts. Where security is concerned, we all have the same goals, Linux, *BSD and commercial Unix vendors and users alike. Working together, wherever possible, is the right choice to make.
Falling Apart at the Seams (SecurityFocus). Here's an article on SecurityFocus which looks at complex security problems and their avoidance. "This new class of holes is different: a programmer doesn't understand what somebody else was thinking or expecting, and fails to make a smooth transition between the two pieces of code. Sometimes the transition appears smooth, but the underlying complexity scuttles system security in the end.The key to solving this problem is the open source movement, and its propensity for keeping code development simple and ego-free."
Open Sources: Wild ICAT adventure (cont.) (ZDNet). ZDNet reports on the ICAT project. "The idea: to make it possible to search for specific security vulnerabilities in computer systems and locate appropriate databases, fixes and patches". Via the offices of Alan Paler (SANS Institute), it appears that the National Institute for Standards and Technology (NIST) may pick up the tab for an expanded ICAT program in the future.
glibc vulnerabilities.This week has been full of advisories from various Linux distributions regarding two severe problems with glibc. Confusing the issue, more than one vulnerability is involved and they were reported at different times. That means that some of the updates only fixed the first reported problem, while others fixed both problems. We'll try to sort out the confusion.
ld.so environment variable vulnerability. Advisories for this problem showed up last week before we even found this report on BugTraq, from Solar Designer, about the problem. The following updates, which came out last week, address just this problem:
format string vulnerability in locale. The locale subsystem in glibc is used to provide internationalization support. A format string vulnerability in locale can be locally exploited to gain root access (or in some cases, remotely exploited). Note that this problem is not specific to Linux; it has also been reported to affect several Unix operating systems, though FreeBSD and OpenBSD are apparently not impacted. The following updates address both the environment variable vulnerability and the locale vulnerability:
PHP upload vulnerability.A PHP vulnerability was reported based on the manner in which PHP handles file uploads. Rasmus Lerdorf acknowledged the problem, provided a patch and indicated that the PHP CVS archives now also include this patch. Also of interest may be this post from Signal 11, which includes a user code snippet for detecting and preventing an exploit based on this vulnerability.
Star Office phones home. Last week, there was a large hullabaloo about the discovery that the Microsoft Office file formats allowed embedded HTML to be executed by a user without their knowledge. This was referenced as a document format being able to "phone home". Although the capability is potentially useful, there was strong agreement that an application should warn the user first, to prevent this capability from being exploited for malicious or anti-privacy purposes.
This week, Kurt Seifried pointed out that Star Office also 'phones home'. He verified that StarWriter, StarCalc and StarImpress all use file formats in which embedded HTML text is automatically executed, without any warning to the user. No response from Sun about this problem has been seen as of yet.
Helix go-gnome script. In addition to their binary installer, Helix Gnome also offers an installation script, "go-gnome". Another BugTraq posting has reported that this script suffers from the same problems previously reported in their binary Installer. The vulnerability can be used to overwrite any file on the system
Both a workaround and a patch for go-gnome are provided in the original report. In addition, Helix Gnome has issued an official update to go-gnome.
Helix continues to take criticism for their responsiveness to security problems, since the initial posting was sent a week before to Helix without receiving a response. In addition, the original bug report and this followup both pointed out additional security issues to which Helix has not responded. Further postings indicate that the problem has been reported, in multiple forums for over a month and a half.
screen setuid root vulnerability.A vulnerability in screen 3.9.5 and earlier that can be exploited by a local user to gain root was recently reported. Note that screen must be installed setuid root in order to be exploited.
Remotely exploitable mopd vulnerabilities.FreeBSD issued an advisory warning of several vulnerabilities in mopd that are remotely exploitable. No specific details are provided, but people using MOPD (an older protocol used for booting older DEC machines such as VAXen and DECstations across the network) are encouraged to either remove the mopd port or upgrade their mopd packages.
FreeBSD's Linux binary compatibility mode. A potential kernel stack overflow in FreeBSD's Linux binary compatibility mode can lead to a system compromise, reports FreeBSD. An upgrade to the latest FreeBSD 3.5-STABLE, 4.1-STABLE or 5.0-CURRENT should fix the problem. This problem should be limited to FreeBSD.
FreeBSD ELF lockup. Also specific to FreeBSD, a system lockup can be triggered by a problem with the ELF binary format. This leaves the system vulnerable to a local denial-of-service attack, since a 15 minute hang can be triggered by an unprivileged user. A kernel patch is provided, or the system can be upgraded.
brouted gid kmem vulnerability. FreeBSD issue an advisory warning that the brouted dynamic routing daemon is erroneously installed setgid kmem. As a result, it can be locally exploited to gain root access. Removing the setgid bit should fix the problem. Updated packages have also been made available. This vulnerability could impact other operating systems that include the brouted daemon.
GNOME esound file permissions problem.FreeBSD has reported a file permissions problem in esound, the GNOME desktop component responsible for multiplexing access to audio devices. esound uses a world-writable directory in /tmp for the storage of a Unix domain socket. A race condition allows this to be exploited to compromise the esound user's account (or root, if root runs esound). FreeBSD has made updated packages available and contacted other vendors about the problem.
Commercial products. The following commercial products were reported to contain vulnerabilities:
PGP ADK-related security problem. In last week's Security Summary, we mentioned that the information available was unclear as to whether the freeware version of PGP for Unix/Linux was affected. Greg Louis dropped us a note to point out that the available information was updated soon after publication. On this website, a clear statement is made that the freeware version of PGP for Unix/Linux version 6.0-6.5.2 are vulnerable. An upgrade to PGP 6.5.8 is recommended. Happily, that version is now available for download.
Zope 'mutable object' vulnerability. Check the August 24th Security Summary for details. Two fixes have been released for this problem; only the most recent one fixes all issues. The updates below are ones that contain the second fix. Check the August 17th Security Summary for additional distribution updates that include the first fix only.
This week's updates:
mgetty temporary link vulnerability. Check last week's Security Summary for details. An upgrade to mgetty 1.2.22 should fix the problem.
This week's updates:
Netscape 'Brown Orifice' vulnerability.Check the August 10th Security Summary for more details.
This week's updates:
perl/mailx. Check the August 10th Security Summary for details.
This week's updates:
xlockmore.Check the August 24th Security Summary for details. An update to xlockmore 4.17.1 is recommended.
This week's updates:
xchat URL handler bug. Versions of xchat from 1.3.9 through and including 1.4.2 can allow commands to be passed from IRC to a shell. Check BugTraq ID 1601 for more details.
This week's updates:
Portable OpenSSH 2.2.0p1. Version 2.2.0p1 of portable OpenSSH was announced this week. The new version now includes DSA key support, Random Early Drop connection rate limiting, and improved interoperability with SSH.COM's ssh 2.3.0.
ICMP Usage In Scanning v2.0 - Research Paper. Ofir Arkin has issued an updated version of his research paper on the use of ICMP in scanning the Internet for host detection, operating system fingerprinting and more.
Jukka Lahtinen minicom.Check last week's Security Summary for details. No official updates have been seen as of yet. Unofficial reports indicate that Red Hat 6.1 and 6.2 and Slackware 7.0 are vulnerable and that SuSE, Linux-Mandrake, FreeBSD, Debian and (reported this week) Conectiva are not vulnerable.
September/October security events.
Section Editor: Liz Coolbaugh
September 7, 2000