![[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 Letters All in one big page See also: last week's Security page. |
SecurityNews and EditorialsDefining a reasonable disclosure process. Steve Christey and Chris Wysopal have released a draft document titled "Reasonable Disclosure Process;" which is in the process to become an IETF standard. This document attempts to lay out the responsibilities of all those who have to deal with security vulnerabilities. Since it touches on the controversial topic of disclosure, there is likely to be some disagreement on what the document says. As might be expected, the draft tries to balance the interests of vendors, customers, and those who discover security holes. It provides a detailed and formal set of events that is supposed to happen:
In general, people who discover vulnerabilities are not supposed to announce them generally until the release stage has been achieved. The vendor is supposed to provide a status update to the reporter every seven days, and the reporter should keep silence as long as the vendor appears to be making a good faith effort toward a solution. This process could drag on for some time: The Reporter SHOULD recognize that it may be difficult for a Vendor to resolve a vulnerability within 30 days if (1) the problem is related to insecure design, (2) the Vendor has a diverse set of hardware, operating systems, and/or product versions to support, or (3) the Vendor is not skilled in security. What happens if the vendor is not serious? The draft calls for a "coordinator" role; the coordinator should arbitrate between the reporter and the vendor, and help decide if a disclosure of the vulnerability is called for. Who are these coordinators? The draft is vague: A Coordinator is an individual or organization who works with the Reporter and the Vendor to analyze and address the vulnerability. Coordinators are often well-known third parties. Coordinators may have resources, credibility, or working relationships that exceed those of the reporter or vendors. Coordinators may serve as proxies for reporters, help to verify the reporter's claims, resolve conflicts, and work with all parties to resolve the vulnerability in a satisfactory manner. A role which is so vaguely defined seems unlikely to be filled in a manner that is satisfactory to all parties. Even when a security vulnerability is released, the draft allows a vendor to sit on the details of the problem for 30 additional days. The idea, of course, is to allow time for patches to be applied before more detailed information becomes available. Such a delay may be useful for closed-source code; it won't help much for free software, however. There is currently an open comment period on this draft; see the announcement for information on how to send in your suggestions.
CRYPTO-GRAM Newsletter. Here's Bruce Schneier's CRYPTO-GRAM Newsletter for February. The main topics covered are Microsoft's security PR and Oracle's not-so-unbreakable system. "In addition to making its protocols and interfaces public, we suggest that Microsoft consider making its entire source code public. We're not advocating that Microsoft make its products open source, but if they really want to impress everyone about their newfound security religion, they will make their code available for inspection." Security ReportsDebian security updates to hanterm, ncurses. The Debian Project has issued security updates to hanterm (fixing a set of buffer overflow problems) and ncurses (also fixing a buffer overflow). Buffer overflow in exim. Ehud Tenenbaum has reported a buffer overflow in the exim mailer, versions 3.34 and prior. No known exploits exist at this time.
web scripts.
UpdatesBuffer overflow in CUPS. Versions of the Common Unix Print System prior to 1.1.14 have a buffer overflow vulnerability. (First LWN report: February 14). This week's updates: Previous updates:
Multiple vulnerabilities in SNMP implementations. Most SNMP implementations out there have a variety of buffer overflow vulnerabilities and should be upgraded at first opportunity. See this CERT advisory for more. (First LWN report: February 14). This week's updates:
Previous updates:
Multiple vendor telnetd vulnerability. This vulnerability, originally thought to be confined to BSD-derived systems, was first covered in the July 26th Security Summary. It is now known that Linux telnet daemons are vulnerable as well.
This week's updates: Previous updates:
Remote command execution vulnerability in uucp. The uuxqt utility in the uucp package does not properly check its options, allowing an attacker to run arbitrary commands. (First LWN report: January 24, 2002). This week's updates: Previous updates: ResourcesSecurity: Key Players - HP (IT-Director). IT-Director sees HP as a growing force in computer security. "HP development in the Linux area is concentrated on providing secure compartmentalisation. The target market for this is primarily service providers, who are keen to deploy high specification servers that can support multiple clients. Plainly, there must be strong security separating individual clients. Linux is popular in the service provider market, and there is also interest from SAP." Linux security week. The and publications from LinuxSecurity.com are available. 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: Jonathan Corbet |
February 21, 2002
LWN Resources | |||||||||||||||||||||||||||||||||
Copyright © 2002
Eklektix, Inc., all rights reserved
Next: Kernel