Trusting free software projects with security information [LWN.net]

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.

(Log in to post comments)

Trusting free software projects with security information

Posted Jun 27, 2002 12:47 UTC (Thu) by gleef (guest, #1004) [Link]

If that is the case, then why is their conduct with the OpenSSH vulnerability (where they aparently worked quietly with Theo and other developers) so drastically different than their conduct with Apache?

They messed up with Apache. They should admit it, promise not to do it again, and move on. Making a policy of not notifying Free software project developers is dangerous, particularly when their standard is different for commercial vendors (with no need to keep confidentiality either).