LWN.net Weekly Edition for June 27, 2002 [LWN.net]

The 2002 Kernel Developers' Summit

The 2002 Linux Kernel Developers' Summit was held June 24 and 25 in Ottawa, Ontario. At this event, a number of issues relevant to the latter part of the 2.5 development series were worked out. LWN's Jonathan Corbet was there, and has written up the experience.

Day One covered the Hammer port, kernel parameters, rationalizing the loadable module mechanism, virtual memory, and the block I/O subsystem.
Day Two was dedicated to what database systems need from Linux, HP's kernel wishlist, the Loadable Security Module, asynchronous I/O, SCSI, and the kernel release process. Among other things, a firm date has been set for the 2.6 feature freeze.

Look inside the individual days' coverage for the details.

Comments (1 posted)

Trusting free software projects with security information

Internet Security Systems, which has been feeling quite a bit of heat for its premature revelation of the Apache "chunk handling" vulnerability, posted an "advisory response" to defend itself on June 21. It is an interesting bit of excuse-making, with references to available patches and "Presidential Decision Directive 63." Buried deep within, however, is an interesting claim:

Due to the general nature of open-source and its openness, the virtual organizations behind the projects do not have an ability to enforce strict confidentiality. By notifying the open source project, its nature is that the information is quickly spread in the wild disregarding any type of quiet period. ISS X-Force minimizes the quiet period and delay of protecting customers by providing a security patch.

This is quite a claim: ISS is telling us that free software projects can not be trusted with information on vulnerabilities in their own code.

It would be most interesting to see the evidence from ISS to back up this claim. Most free software developers (though there are always exceptions) are greatly concerned about potential vulnerabilities in their code. They care about their users, and will do their best to get a real, tested fix out before spreading the word of the vulnerability. It is not in the nature or interests of free software developers to put their users at risk.

That said, there are things that free software projects could do to help people who discover vulnerabilities. The most important thing would be to make it clear who should be contacted when a vulnerability is found. After all, sending the notification to a general project mailing list is not usually what one wants to do. But many or most project web pages offer little help to somebody wondering how to report a security hole.

Any development project which would prefer not to learn about its own security problems on Bugtraq must make an effort to do better. The project documentation and web site should offer clear contact instructions for the reporting of security problems. The security contacts should know how to respond quickly to reports, and have the ability to get a patch out to users. The procedures for responding to a security problem need to be worked out before the next vulnerability turns up.

There is no reason why free software project development teams can not be at least as trustworthy as proprietary vendors when it comes to vulnerability information. Claims that free software developers have overly loose lips are not justifyable. But developers who want to be given a chance to fix their holes before they become public need to take steps to show that they are serious about security, and they should make it easy for people to report the problems that are found.

Comments (1 posted)

Letters to the editor

When LWN switched over to the new site a few weeks ago, some of our readers worried that the comment posting facility would bring about the end of the Letters to the Editor page. After all, why bother writing a letter when it is easy to attach comments directly to articles? That was not a consequence that we had feared, but now we are beginning to wonder - no letters to the editor have been received this week. Thus, there is no letters page in this Weekly Edition.

For the most part, we have been pleased with how the comments feature has worked out so far. There have not been huge numbers of comments, but most of those we have seen have been of high quality. Our trust in our readers has proved itself justified - most of the time.

We did not want to drop the Letters to the Editor page, however. The Letters page has, over the years, been a valuable source of feedback and a place for LWN readers to express their opinions. So we hope that this week's lull proves to be a temporary thing; perhaps all of our letter writers are at OLS this week. If you have an opinion on something that you would like to see published, please do not hesitate to send it our way; letters should be sent to letters@lwn.net

Comments (12 posted)

Page editor: Rebecca Sobol

Security

Security news

OpenSSH 3.4

OpenSSH 3.4 was released just five days after the release of version 3.3. The release closes "at least one major security vulnerability"; upgrading to 3.4 is recommended. Please see the vulnerability report for a list of security alerts from distributors as they become available.

OpenSSH provides a critical entry point to many systems on the net; this could be nasty. If you plan to wait for an update from your distributor, please consider setting UsePrivilegeSeparation yes or ChallengeResponseAuthentication no in sshd_config to avoid the vulenrability. UsePrivilegeSeparation is only available in OpenSSH versions 3.2 or 3.3. Setting ChallengeResponseAuthentication may impeed customary access for some or all of your users.

Version 3.3 firmed up "privilege separation" support, and made it the default. Essentially, privilege separation works by splitting the ssh server into two cooperating processes. One process is charged with talking to the network; it runs without privilege. The other process sits back, makes decisions, and hands out privileges when it's convinced that is the right thing to do.

The end result is that there is little to be achieved by compromising the "front line" process. Even if somebody does discover a vulnerability in that code, it can not be used to gain access to the system. The privileged process, by virtue of its simplicity and its separation from the network, is far easier to verify as being truly secure.

The 3.4 release closes the serious vulnerability described in advisories from OpenSSH and ISS. The vulnerability prompted a week long code audit by the OpenSSH team which resulted in "many other fixes. We believe that some of those fixes are likely to be important security fixes."

Comments (2 posted)

Updated Apache advisory and response from ISS

The Apache Software Foundation has issued an updated advisory on the "chunk handling" vulnerability. Now that a 32-bit remote exploit is circulating, an Apache upgrade is suggested even more urgently than before.

Meanwhile, ISS has sent out a response to the extensive criticism it has taken for having announced the vulnerability without allowing the ASF (or anybody else) any time to prepare patches. "Due to the general nature of open-source and its openness, the virtual organizations behind the projects do not have an ability to enforce strict confidentiality. By notifying the open source project, its nature is that the information is quickly spread in the wild disregarding any type of quiet period. ISS X-Force minimizes the quiet period and delay of protecting customers by providing a security patch." If you haven't already, see this week's Leading Items for our opinion.

See the vulnerability report for current information on this problem and distributor alerts.