Linux in the news
All in one big page
See also: last week's Security page.
NewsOpen Source is Critical to Security. We've made that statement, so have many others and we realize that we are preaching to the choir when we repeat it here. However, if you've been having difficulties convincing people around you, try using this week's discovery of a second encryption key in many versions of Microsoft Windows, named "_NSAKey". It was a hot topic in the press, which you can check out in these articles and commentaries: Cryptonym site, where Andrew Fernandes first posted his discovery. Microsoft has issued a flat denial, which calls the second key a "backup" key, to be used in case the first key was no longer available.
For a relatively balanced reaction, check out this editorial from NTBugTraq editor Russ Cooper. While willing to accept Microsoft's response, he points out that the fact that the second key exists makes the system highly insecure.
In theory, you create your own CSP to replace Microsoft's supplied CSP (implementing whatever you wanted in it, say boosting 40-bit to 128-bit), modify the second key to one of your own, install your CSP over Microsoft's, and fire up any application that uses CryptoAPI. The signature will fail Microsoft's verification, pass yours, and everything should work as if you had a U.S./Canadian version.Security through obscurity fails again. In an open-source model, the reasons for introducing a second key would be well-known and people would have pointed out the pitfalls in advance. From the information available, it seems likely that an unwise name was chosen for this particular key, causing a large furor. The end result, though, is that you will never be guaranteed that the software does not have a backdoor, using this mechanism or some other, without access to the source.
Lest open source be considered a panacea for all security problems, though, remember both the number of security bugs that continue to be found and fixed in open source software, such as those reported this week. It is good to have the source, it is good to find and fix bugs, but that is not always enough. For another take on the issue of trust, check out this article by Ken Thompson in 1995 [Thanks to Dave Stevens].
On the side of the conspiracy theorists, it is interesting to link up this week's disclosure with this Wired News article, first mentioned in our May 20th Security Summary, where a report to the European Parliament's Science and Technology Options Assessment Panel (STOA) mentions a possible backdoor in Lotus Notes and other software, introduced in cooperation with the NSA. Whether or not you believe the rumors of backdoors in commercial software, it appears that high level officials in Europe are certainly willing to give them credence.
Security Portal featured an article on Secure Linux Distributions this week. They give brief summaries of the work currently going on with kha0S, Secure Linux and Bastille Linux, talk about the differing goals of the distributions and happily mention that Secure Linux, based on Debian, and Bastille Linux, based on Red Hat, will be coordinating with each other.
Security ReportsProFTPD. We mentioned last week that LinuxPPC, Red Hat and Yellow Dog Linux had released updates to ProFTPD. Those updates were prior to this week's announcement of ProFTPD 1.2.0pre5, which followed closely on the heels of 1.2.0pre4. Neither 2.1.0pre4, nor the patches posted to Bugtraq, fixed all of the recently reported security problems, so upgrading to 2.1.0pre5 is recommended. Expect to see yet another round of updates from distributors over the next week.
For the longer term, it seems the ProFTPD may have a rocky future. It has a new maintainer, which is fine, but there are apparently some concerns that the design of ProFTPD is such that securing it is not going to be an easy task. ProFTPD has such a rich feature set, though, that people are likely to take on the task anyway.
RH 6.0 shadow passwords. Under Red Hat 6.0, locking and then unlocking an account with the "passwd -l user" and "passwd -u user" commands can result in the addition of a control character to the end of the password field in the shadow password file. Red Hat has acknowledged the bug and Mihai Ibanescu has posted a patch for it.
Dynamic DNS is vulnerable. Although a note to this effect was posted this week to Bugtraq, it should be noted that Dynamic DNS is known to be inherently insecure and always has been. Solutions are underway, but not yet available. If you are concerned about security, avoid Dynamic DNS for the present.
Commercial software vulnerabilities. A problem was reported with the WatchGuard Firewall default configuration.
UpdatesUpdates for the INN vulnerability reported in last week's security section are available for: last week's security section, in addition to the ones we mentioned from Caldera, Debian, Red Hat and SuSE, came this week from Linux-Mandrake.
They also provided an update for the vulnerability in amd. See last week's issues for details on that.
Red Hat has announced an updated set of XFree86 packages for the 4.*, 5.* and 6.0 distributions. This update includes some security fixes, and should probably be applied.
ResourcesTesting of Cisco's VLAN implementation was done by Dave Taylor and Steve Schupp, who made their findings available. Some comments on the findings may also be of interest.
Section Editor: Liz Coolbaugh
September 9, 1999
Secure Linux Projects Bastille Linux
Khaos Linux Secure Linux
Security List Archives
Firewall Wizards Archive
Red Hat Errata
Comp Sec News Daily
Linux Security Audit Project