[LWN Logo]
[LWN.net]

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.


News and Editorials

Linux Distribution Security Report. SecurityPortal's Kurt Seifried released his Linux Distribution Security Report this week. In it, he analyzes security information released from Red Hat, SuSE, TurboLinux and Caldera, including a look at the number of security reports for each release, the time between a vulnerability report and the release of a fix and a brief comparison of the overall efforts of each distribution.

Even though he initially decides to throw Slackware and Debian out of his calculations because of their "ridiculously slow release schedules", he later includes them in his conclusion and commentary -- an unfair treatment that, not unexpectedly, produced a response. Jeffrey Baker pointed out on Slashdot that Slackware releases just as often as Red Hat does. Joey Hess responded for Debian. He also pointed out that Debian's minor releases, which are put out just for the purpose of providing an easy mechanism for installing an already patched system, were not counted. It appears that Patrick Volkerding was correct in inflating the version number for Slackware from 4.0 to 7.0 to prevent the misapprehension that Slackware was any further "behind" other distributions.

Those problems aside, Kurt's analysis is still very useful and interesting. He ends with a detailed checklist of what a distribution ought to do to make it easier for its customers to stay secure. It is an excellent and useful list. Most of the items on it are one's that we'd like to see done for every distribution out there, not just the major distributions that normally issue security advisories. Here are a few of our favorite suggestions, paraphrased:

  • Make a /security/ directory on your website (e.g., http://www.debian.org/security/), so that finding security information is easily done for every distribution.

  • Have security mailing lists and use them. Spotty forwarding of your own advisories to your own security lists encourages people to ignore them.

  • Monitor general Unix vulnerability reports and the updates from other distributions (this has been happening much more in the past year, but was very little done before that). We still put up some vulnerability reports on this page and then wait for updates, only to receive one or two or none for a problem we know affects some or all distributions.

  • If a vulnerability has been reported and your distribution is not affected, send out an advisory to that effect and tell us why. That lets us know that the vulnerability is not being ignored.
He listed many other useful ones, though we might add a couple more that didn't make it onto his list:
  • Issue a separate advisory for each vulnerability, rather than lumping multiple vulnerabilities/fixes into one page or advisory. This makes it easier for the multitude of security news systems (including this one) to compare distributions and determine which have or have not issued updates for a specific problem.

  • Credit the source of the original vulnerability report, whether a specific author or vendor, and provide links to the original reports whenever possible. This is also important to help coordinate and determine exactly what problems are being fixed by a given update as well as to give credit to people who took the time to report the problem initially.
Let us all remember, though, as we analyze and use hindsight to judge what "should" have been done, that behind each of these distributions lies individuals. Check the history of security reporting from any distribution and sometimes they did it well, sometimes poorly. There was usually an untold story behind that history, someone new put in charge of a task no one was doing, who charged ahead and set things right, good people whose talents were recognized and therefore were pulled out of this work into other areas, leaving gaps in process and activity that were quite visible and more.

The management of the various distributions has started to recognize both the PR value and landmines inherent in the security field. Do the job well and you have an excuse to get your name out there constantly, reminding people of your distribution without paying for expensive press releases. Do the job poorly and you'll provide good fodder for a journalist looking for a reason to rant and rave. In the end, their ability to hire good people, treat them well and keep them, will determine the quality of their security services.

ACLU asks for FBI source code. Open source code entered the legal arena from a different avenue this week when the ACLU sent a Freedom of Information Act (FOIA) request to the FBI, asking for details on the "cybersnoop" programs, Carnivore, Omnivore and Etherpeek. The details they requested included the source code to the programs, something the FBI has denied previously on the basis of both security and the rights of the commercial software developers who produced parts of these programs.

To the ACLU's knowledge, the request for program source code is the first of its kind. But Steinhardt said that two federal appeals court rulings that computer code is a form of speech, no different from any other written document, support the ACLU's demand under the the Freedom of Information Act. The Act gives Americans broad rights to obtain written information held by the federal government.

Openhack results. The Openhack contest ended this week when the Openhack database was successfully cracked. The winner? "The crack was performed by none other than Spanish security consultant Lluis Mora, the same person who felled eWEEK Labs' previous security test site."

Three new vulnerabilities in MiniVend were found, along with a vulnerability in a Solaris add-on. Details are not being published until the vendors have an opportunity to provide fixes. The contest ended with a report on the Openhack hardening techniques used to secure their server. Note, though, that it is hardest to protect from simple errors; the latest hack was partially made possible when a simple step in the hardening process was accidentally skipped and a vendor default password was left unchanged. That gives a good example of why vendor software should not be shipped enabled with a default password.

Vulnerability Reporting Assistance. Due to recent record-levels of vulnerability reports, and the erratic quality of some of them, the folks at SecurityFocus are now offering vulnerability reporting assistance. Free of charge, and, they promise, no-strings-attached, they'll offer assistance in preparing advisories, finding vendors to contact prior to posting and more. "This is not a pay service in any way shape or form. It's actually being performed by the staff here outside of our regular work and on a volunteer basis."

An improvement in the quality of advisories and better coordination with vendors should be helpful to everyone who believes in responsible, full disclosure reporting of security problems.

GSA Rethinks FIDNet solution (FCW.com). The government will reissue their RFP for a Federal Intrusion Detection Network (FIDNet), according to this article. The new RFP will be restricted to systems staffed and monitored by the vendor. We certainly hope one or more of our open-source-community security vendors takes a crack at this offering ...

Another brick in the wall (IBM developerWorks). Subtitled "Fighting a losing battle on the front lines of security", this IBM developerWorks article addresses the basic need to build security into a network from the ground up. "It's a given that your network/security administrators are fighting a losing battle. They probably don't have the time, training, or resources to adequately secure your corporate network. I know this, because I spent the last five years being that outside consultant, working on networks like your own. For administrators, the hardest part of all this, usually, is getting management to allot you the time and resources to develop a plan. "

For your amusement. Segfault.org has issued RFC 31337, the initial draft of a new standard. "Unified Backdoor Protocol Specification. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited."

Mail server filters. Because Linux or *BSD is frequently used for mail servers at sites containing desktop systems running other operating systems that are vulnerable to a variety of e-mail based attacks, it is not uncommon to see a virus alert followed by suggestions for improved mail filters for the mail server to filter out such attacks. The following filters were posted to BugTraq in response to one of the most recent Outlook-based attacks:

Security Reports

Netscape JPEG COM marker processing vulnerability. Netscape 4.73 and earlier and Mozilla M15 and earlier can be, under limited circumstances, used to execute arbitrary assembly code due to the manner in which they process JPEG COM markers. Solar Designer's detailed announcement of this vulnerability provides a wealth of evidence and detailed information. In the meantime, an immediate upgrade to Netscape 4.74 or Mozilla M16 is highly recommended. Distribution updates for Netscape 4.74 are likely to start rolling in very soon.

Red Hat security update to PAM. Red Hat has put out a security update to PAM fixing a problem in that module. If you are running a display manager and XDMCP has been enabled, unprivileged users can fake a console login and shut down the machine.

Multiple gpm vulnerabilities. New problems with gpm have been reported, including the ability for a local user to execute arbitrary commands with elevated group privileges and a local denial-of-service attack. Check BugTraq ID1512 for more details.

This week's updates:

Roxen Webserver. The Roxen webserver is a GPL'd webserver that is shipped with Debian, SuSE, Linux-Mandrake and FreeBSD. On July 21st, a report to BugTraq indicated that Roxen 2.0.46 contained a couple of vulnerabilities that could allow information such as the site administrator's encrypted password to be obtained. Subsequent tests confirmed the problems. An official advisory has also been released, recommending an upgrade to Roxen 2.0.69 (or 1.3.122) to fix these problems.

Cgi-bin/Servlet vulnerabilities.

Updates

Updates to updates were popular this week...the rpc.statd, openldap and inn entries below are included again primarily due to updated advisories from at least one vendor.

NFS/rpc.statd . Check last week's Security Summary for more details.

dhcp. A second set of problems with the ISC dhcp client was reported in last week's Security Summary. New updates to dhcp-3.0b1pl17 (instead of pl12) are now coming out.

inn verifycancels vulnerability. Check the July 13th Security Summary for details. ISC released inn 2.2.3 this week, with an official fix.

wu-ftpd. Check the June 15th Security Summary for more details. wu-ftpd 2.6.1 contains fixes for this problem.

openldap tmplink vulnerability. A tmplink vulnerability was reported in openldap. Check the April 27th LWN Security Summary or Red Hat Bugzilla ID 10714 for more details.

This week's updates:

Previous updates:

Resources

New open source tools released by Razor. Just in time for the Black Hat conference, Bindview's RAZOR team announces the release of two new software tools, VLAD the scanner and Despoof, a spoofed-packet checker. A brief review of the license under which the tools are released reveals a probably-Open-Source license, at least in this editor's opinion.

LinuxSecurity.com weekly newsletter. For those of you who still haven't gotten enough, here is LinuxSecurity.com's weekly security newsletter.

Events

Call for Papers: Computer Security 2000 and International Computer Security Day. The Call For Papers for both Computer Security 2000 and International Computer Security Day (DISC 2000) has been released. Submissions are due by September 22nd, 2000. The two events will be held together from November 26th to December 1st, 2000, in Mexico City, Mexico. Computer Security 2000 is an annual ACM (Association For Computing Machinery) event.

July/August security events.
Date Event Location
July 26-27, 2000. The Black Hat Briefings Las Vegas, Nevada, USA.
July 28-30, 2000. DEF CON VIII Las Vegas, Nevada, USA.
August 14-17, 2000. 9th Usenix Security Symposium Denver, Colorado, USA.
August 14-18, 2000. Ne2000 (Networking 2000) Lunteren, The Netherlands
August 18-20, 2000. Hack Forum 2000 Ukraine
August 20-24, 2000. Crypto 2000 Santa Barbara, California, USA
Aug 22-23, 2000. WebSec 2000 San Francisco, California, USA
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


July 27, 2000


Secure Linux Projects
Bastille Linux
Immunix
Khaos Linux
Nexus
Secure Linux
Secure Linux (Flask)
Trustix

Security List Archives
Bugtraq Archive
Firewall Wizards Archive
ISN Archive

Distribution-specific links
Caldera Advisories
Conectiva Updates
Debian Alerts
Kondara MNU/Linux Advisories LinuxPPC Security Updates
Mandrake Updates
Red Hat Errata
SuSE Announcements
Yellow Dog Errata

Security Software Archives
munitions
ZedZ.net (formerly replay.com)

Miscellaneous Resources
CERT
CIAC
Comp Sec News Daily
Crypto-GRAM
LinuxLock.org
Linux Security Audit Project
LinuxSecurity.com
OpenSSH
OpenSEC
Security Focus
SecurityPortal

 

Next: Kernel

 
Eklektix, Inc. Linux powered! Copyright © 2000 Eklektix, Inc., all rights reserved
Linux ® is a registered trademark of Linus Torvalds