![[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 Linux History Letters All in one big page See also: last week's Security page. |
SecurityNews and EditorialsAnother set of vulnerabilities in bind came to light this week. Bind, of course, is the DNS server used over most of the Internet. So vulnerabilities in this package need to be taken seriously.An overview of the problem can be found in this CERT advisory. As they say, "...these vulnerabilities present a serious threat to the Internet infrastructure." Those craving more detail may want to look, instead, at this advisory from COVERT Labs, which gets down into the code and explains exactly how a couple of the bugs come about. There are two problems with bind 8.2.2. The most serious is a buffer overflow in the handling of "transaction signatures." This overflow happens regardless of the nameserver's configuration options; it appears to be difficult to exploit, but somebody will probably achieve it anyway - they usually do. There is another bug that can expose the nameserver's environment variables. Bind 4 has a couple of additional problems of its own. Fixes are available for this ancient version of the server, but such a critical service should really be running with more modern software. The Internet Software Consortium and Nominum (which wrote bind 9) responded with this press release entitled "Upgrade to BIND Version 9.1 Software Imperative." In fact, upgrading to 9.1 is not "imperative;" version 8.2.3 contains fixes for all of the known problems. It is true, however, that version 9 is where the current development activity is happening, and that administrators should be thinking about an eventual upgrade. Meanwhile, the major Linux distributors all still ship bind 8, and most have been quick to come out with updates: Bind vulnerabilities have, in the past, been widely exploited. It would be nice if it were different this time. The information and the updates are all available; the exploits do not yet exist. People who move quickly need not worry about this problem. DirecTV strikes back. For those who have not seen it, a perusal of this SecurityFocus article is worth the time. DirecTV is a large satellite television provider in the U.S. It seems that the DirecTV receivers are set up so that DirecTV can reprogram them via the satellite. On January 21, the company made use of that capability to permanently disable a large number of receivers that had been, shall we say, "modified" to allow reception of more programming than had been paid for. One estimate we've seen says that over 100,000 receiver cards were destroyed. Those who traffic in pirated cards are apparently referring to the event as "Black Sunday." There are a couple of interesting aspects to this story. The first is, once again, the difficulty of protecting information in modern times. Even well-guarded information gets out; imagine the challenges in protecting something that you (1) broadcast to an entire continent via satellite, and (2) deliver via a receiver that is under the user's control. Dealing with pirates will be a never-ending hassle and expense for a company like DirecTV, and it may well be a battle that the company ultimately loses. Charging for information is a hard way to go. Then, one can look at DirecTV's tactics. One need not have sympathy for TV pirates to wonder about the propriety of remotely programming somebody's hardware to destroy itself. In the free software world, we like to know what is running on our hardware and exactly what it can do. Consumer electronics, instead, is increasingly heading toward proprietary code that implements the vendor's agenda. That code is often quite hostile and restrictive; consider, for example, the DVD region coding scheme. Or, for that matter, a satellite television receiver that self destructs for Canadian citizens who can not legally buy the service. If DirecTV can program a receiver to destroy itself, what other, hidden functionality can it implement? Just how closely does that box monitor your viewing habits? How easy would it be for somebody other than the vendor to invoke the "self destruct" mechanism? What sort of (InterBase-like) backdoors live in that code, unknown even to the vendor? Wouldn't it be nice to know what is really happening inside that box? Linux is poised to be a dominant force in embedded systems; it is increasingly showing up in places like, well, TV set-top boxes. The use of Linux in such a box requires that the vendor make the GPL-covered source available. There are no such constraints on any add-on code produced by the vendor. But the first set-top box vendor who distributes all the source, and provides a way for users to update their software, may find that a whole community of people is out there just waiting to write useful add-ons. Such a device could sell well indeed, and could reward the vendor well. Assuming, of course, that said vendor does not wish to include capabilities that users do not want. Call for testing: a new secure FTP server. Chris Evans has written a new FTP server called "vsftpd." It is designed from the beginning to have a higher level of security than other FTP servers, and is licensed under the GPL. He has now made a beta release and is looking for people who can help him test it out and audit the code. "Security holes protect your equipment" Many companies try to gloss over their security holes. Others issue a fix and try to put the whole thing behind them as quickly as possible. But it's rare to see a web page like this Asanté product page that brags about security holes as a positive feature. Yes, of course, the "holes" in question are physical holes in the case allowing the product (a network hub) to be tied down. Security ReportsDebian/Sparc-specific OpenSSH update. Debian reported a PAM-based problem with the OpenSSH packages for Debian on the Sparc this week. They also issued an updated version of the original advisory with a corrected description of the problem and recompiled OpenSSH packages. Upgrading to the packages listed in the second advisory is recommended.Trustix-specific OpenLDAP bug. Trustix issued updated OpenLDAP packages to fix a "silly bug in the rpm spec file", which set OpenLDAP to run by default. Trustix users should check the status of OpenLDAP on their system and disable it if they do not need to use it. Resource exhaustion bug in Red Hat 6.2 inetd. Red Hat has issued an update to inetd for its 6.2 release. It seems that inetd, when implementing internal services (such as echo), forgot to close the socket for the connection. Eventually it will run out of sockets and things will stop working. Red Hat 6.2 shipped with all of the internal services disabled, so this fix only really matters for people who explicitly turned them on. Format string trouble with man. A format string problem has been reported with man on (at least) the SuSE and Debian distributions. Thus far, neither exploits nor fixes are known to be available. The man command, of course, is not a terribly privileged operation, so the level of worry is probably pretty low.FreeBSD turns up some problems. FreeBSD has posted a few alerts resulting from problems they found while auditing their code. They are:
cgi-bin scripts. The following cgi-bin scripts were reported to contain vulnerabilities:
Commercial products. The following commercial products were reported to contain vulnerabilities:
Updatesmicq remotely exploitable buffer overflow. Check the January 25th LWN Security Summary for the original report or BugTraq ID 2254. This vulnerability can be exploited remotely to execute arbitrary code. micq 0.4.6p1 contains a fix for the problem.This week's updates: Previous updates:
icecast format string vulnerability. Check the January 25th LWN Security Summary for the original report. This can be exploited remotely to execute arbitrary code. Exploits for Slackware and Red Hat have been published.This week's updates: Previous updates:
glibc local write/ld.so.cache preload vulnerability. Check the January 25th LWN Security Summary for the initial report. This can be exploited to create/overwrite files without authorization.This week's updates: Previous updates:
MySQL buffer overflow. Check the January 25th LWN Security Summary or BugTraq ID 2262 for the original reports. This can be exploited remotely to gain access to the system under the uid of the mysql server. MySQL 3.23.31 and earlier are affected. MySQL 3.23.32 fixes the problem.This week's updates: Previous reports:
webmin tmpfile vulnerability. Check the January 25th LWN Security Summary for the original report. webmin 0.84 contains a fix for this problem.This week's updates: Previous updates:
crontab file access vulnerability. Check the January 25th LWN Security Summary for the original report.This week's updates: Previous updates:PHP Apache Module per-directory and virtual hosts vulnerabilities. Check the January 18th LWN Security Summary for the original report of the problems. An upgrade to PHP 4.0.4pl1 will resolve the issues.This week's updates: Previous updates:
tinyproxy heap overflow attack. Check the January 18th LWN Security Summary for the initial report. This can be exploited to cause a denial-of-service. tinyproxy 1.3.3a has been released to fix this problem.This week's updates: Previous Updates:
squid tmprace problem. Check the January 11th LWN Security Summary for the initial report.This week's updates: Previous updates:
Apache tmprace problem. Check last week's LWN Security Summary for the initial report.This week's updates: Previous updates:
inn tmprace problem. Check last week's LWN Security Summary for the initial report.This week's updates: Previous updates:
exmh symlink vulnerability. Check the January 18th LWN Security Summary for the initial report. The Debian and FreeBSD advisories are the first distribution updates for this problem we have seen.This week's updates: kdesu password sniffing vulnerability. The KDE "kdesu" utility has a vulnerability that can allow a local user to steal passwords; see the January 25 LWN Security Section for the initial report. This week's updates are:
LPRng format string vulnerability. It took them a while, but TurboLinux has finally come out with a fix for the LPRng vulnerability first reported in the September 28, 2000 LWN Security section. The full set of updates, now, is:
ResourcesA Python AES implementation. Bryan Mongeau has released an implementation of the Advanced Encryption Suite in Python.
Ramen detection and cleansing (Linuxlock.org). The Institute for Security Technology Studies has posted a detection and removal script for the reported Linux Ramen virus. Bill Stearns is working on a shell script that both detects and removes the Ramen Virus, from RedHat machines. Even though the Media has made a big deal about the Ramen Virus, I am afraid that this shell script solution may be overlooked. This shell script is not just for the security community but the RedHat community as a whole. If you are not sure if you've been infected, please check this script out. (Thanks to Christopher Carella) Linux Advisory Watch. The LinuxSecurity.com Linux Advisory Watch for January 26 is out, with an overview of outstanding Linux security issues. See also the Linux Security Week posting from the same source. EventsUpcoming security events.
For additional security-related events, included training courses (which we don't list above) and events further in the future, check out Security Focus' calendar, one of the primary resources we use for building the above list. To submit an event directly to us, please send a plain-text message to lwn@lwn.net. Section Editor: Liz Coolbaugh |
February 1, 2001
LWN Resources | |||||||||||||||||||||||||||||
Copyright © 2001
Eklektix, Inc., all rights reserved
Next: Kernel