![[LWN Logo]](http://old.lwn.net/images/lcorner.png)
![[LWN.net]](http://old.lwn.net/images/security.png)
|
|
|
 Sections: Main page Security Kernel Distributions Development Commerce Linux in the news Announcements Back page All in one big page See also: last week's Security page. |
SecurityNews and editorialsRed Hat/Piranha security issues: important but not a backdoor. This week, we first heard of the Piranha security problems through normal channels, this Red Hat announcement. It seems that two problems had been found and fixed in Piranha, their in-house heartbeat package, including a binary package shipped with a default password and a vulnerability in the change password function that allowed arbitrary commands to be executed. Both problems are severe and an upgrade is strongly recommended. [Editor: here is an updated version of the original advisory.]So far, the process seemed normal: bugs are found, fixes are generated and an announcement goes out. However, the bugs themselves were originally found and reported to Red Hat by ISS, who issued this press release, entitled "Backdoor Password in Red Hat Linux Virtual Server Package". This seems a bit inappropriate. A backdoor, by all definitions we've heard, is an undocumented method of getting privileged access. The authentication mechanism in Piranha is quite well documented. It was simply an error to ship a preset password for this documented "front door". Well, given last week's coverage of a back door in a Microsoft DLL, the ISS advisory initiated a small media frenzy, with press coverage from: In the end, the media coverage provided little, if any, detail that was not provided in the original security report. Despite efforts to politicize the issue, it remains a case of a couple of programming errors, not intentional back doors, which were correctly found, reported and fixed in a timely manner. Some have accused us of bias in not pursuing and reporting on this issue more aggressively, but there simply was no special issue here, no unique circumstance. If the word "backdoor" had not been introduced, this would have been one of the many security reports we cover each week, not an editorial issue. Upgrade your Piranha packages and move on.Lucent releases buffer overflow prevention library. Lucent has announced the release of Libsafe, a library which defends against buffer overflow attacks. It works by putting a wrapper (they call it "middleware") around dangerous functions that contains any buffer overflows within the current stack frame, so that the return address can not be changed. The press release commented, "Linux distributors Red Hat, Inc., Linux-Mandrake, Turobolinux and Debian GNU/Linux are working with Bell Labs to incorporate Lucent Libsafe into their software releases." This could give the impression that Libsafe will be an integral part of each distribution. In response to this, Wichert Akkerman, Debian Project Leader, clarified Debian's intentions. "David Coe is planning to make a Debian package of LibSafe which will be added to the distribution. However it will be an optional package, which means that people will be able to use LibSafe to add some security to their system if so wanted, but we won't make it an essential part of the distribution." The Slackware team quickly evaluated Libsafe and chose to add it into their "contrib" tree, reported this announcement. Again, though, this is not the same as choosing Libsafe as a default for the distribution. We do not yet have details on the plans of other Linux distributions. How does Libsafe stack up against other stack protection mechanisms? We found a couple of analyses, one from Solar Designer and another from Perry Wagle (StackGuard developer). Libsafe has an advantage over StackGuard in that recompilation of programs is not required and it can be introduced into a system with little impact. In turn, the protection provided by Libsafe is limited to the system calls strcpy, strcat, getwd, gets, [vf]scanf, realpath, and [v]sprintf, unlike StackGuard. Libsafe does not work on statically-compiled binaries and its effectiveness may be dependent on which version of glibc you link against. Slackware pointed out that the use of Libsafe would break backwards compatibility for non-glibc-based software. In addition, Libsafe will not work properly on machines that require some form of pointer alignment, as pointed out by Olaf Kirch. In summary, Libsafe is an excellent addition to the available security tools, but not a panacea, nor a full replacement for existing stack protection tools. Security Reportsopenldap tmplink vulnerability. A tmplink vulnerability was reported in openldap this week. Check Red Hat Bugzilla ID 10714 for details on this problem.This week's reports: LCDproc 0.4 vulnerability. LCDproc, a Linux LCD display driver, introduced a remote vulnerability into the driver in version 0.4. An exploit for Linux/x86 has been published. A patch against 0.4-pre9 has been made available. Alternatively, you can downgrade to version 0.3.
imapd denial-of-service. The imap locking mechanism will prevent a user from accessing their imap mailbox if a lock already exists, even if created by another user, reported Alex Mottram. By combining this vulnerability with the imap problem reported in last week's Security Summary, this produces a remotely-exploitable Denial-of-Service attack. FreeBSD issued two advisories in response to these issues, one addressing last week's reportand another addressing this week's report. No patch is available; they recommend moving to an alternate server. Additional reports of buffer overflows in imapd-wu continue to trickle in. Qpopper fgets(). This report describes a vulnerability in all versions of Qpopper, including 3.0 fc2 and earlier, in which input is improperly verified. No fix has been reported as of yet. Check BugTraq 1133 for more details. SuSE cron: arbitrary file deletion. The SuSE Linux default configuration of cron can be exploited to arbitrarily delete any file on the system, according to this BugTraq posting. No confirmation or update from SuSE as of yet. Sendmail mail.local vulnerability. An input verification problem was reported in mail.local, part of sendmail. An official patch was quickly produced and will be included in the next version of sendmail. PostgreSQL cleartext password storage. Robert van der Meulen pointed out that PostgreSQL stores usernames and passwords in cleartext in pg_shadow, allowing the password mechanism to be bypassed. Versions 6.3.2 and 6.5.3 have been reported to be vulnerable; no official word or update has been seen as of yet. FreeBSD 3.4-STABLE ncurses overflow.. It appears that FreeBSD 3.4 ncursesis vulnerable to a buffer overflow. Note that both 4.0 and 5.0 have been tested and found not vulnerable. CVS local denial-of-service vulnerability. The CVS use of /tmp for locking purposes leaves it open to a local denial-of-service attack, according to Michal Szymanski. Check BugTraq 1136 for a work-around. Commercial Software:Realserver denial-of-service attack. RealNetworks, Inc., has put out an advisoryregarding a potential denial-of-server attack in RealServer. Updated executables have been made available for RealServer 7.0 or RealServer 7.0.1. People using RealServer 6.X or earlier need to contact their customer service department. Cisco Catalyst. Unauthorized access to the enable mode has been reported in the 5.4(1) release of Cisco Catalyst. Upgrades are available and customers are urged to apply them. Cisco IOS. Security scans can cause a Cisco router to reload unexpectedly, due to problems in the Cisco IOS software, allowing a denial-of-service attack. New releases to fix the problem are either currently available or promised to be available in the near future. Adtran MX2800 M13 Multiplexer. A Denial-of-Service vulnerabilityhas been reported in the Adtran MX2800 M13 Multiplexer. Updatesimwheel. For more information, check the BugTraq vulnerability database entry. This vulnerability was first reported on March 13th, 2000.
gpm. Improper permissions handling in gpm was discussed in the March 30th LWN Security Summary.This week's updates:
emacs 20.X.. Problems with emacs 20.X (not XEmacs) were discussed in last week's Security Summary. Generic-NQS (GNQS). See the February 10th, 2000 LWN Security Summary for more details. ResourcesBruce Schneier's CRYPTO-GRAM (April 15th). The April 15th edition of Bruce Schneier's CRYPTO-GRAM covers testing of various cryptographic algorithms in preparation for NIST's choice of a standard for AES. If this will impact your work, you'll want to review his comments and send in your own to NIST. Bruce also comments on UCITA in this month's edition, pointing out that UCITA's choice to allow software manufacturers to remotely disable software in the event of a licensing dispute essentially legislates backdoors into software under the "naive conceit ... that only the manufacturer will ever know this disable code, and that hackers will never figure the codes out and post them on the Internet". Section Editor: Liz Coolbaugh |
April 27, 2000
|
Copyright © 2000
Eklektix, Inc., all rights reserved
Next: Kernel