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
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.
to post comments)