Coordinated security
by havoc
Slashdot
comments are even dumber than usual when discussing coordinated
security updates. I guess I’d expect that if they know nothing else,
at least many Slashdot posters work in IT and understand security
patches!
For those who don’t know: in most cases, a not-yet-public security
flaw has a public announcement date coordinated among all the major
Linux distributions, BSDs, and the upstream project in
question. That’s because most users can’t use tarballs or
project-built binaries, they need packages from their vendor. By
coordinating the announcement date, everyone can patch their systems
at the same moment that the script kiddies can start to use the
exploit. For an already-public flaw, of course, there’s no value in a
coordinated release date and everyone scrambles to ship the fix
ASAP.
The lag between announce and patch can be large if the announce date
isn’t coordinated, because so many versions of so many operating
systems need to be patched. Often the patch has to be backported to
multiple versions of a package, which can be complicated. Then the fix
has to be built (for something like Mozilla or OpenOffice.org, this is
not fast), tested, documented, and pushed out for download.
If you’re an open source project maintainer, you need to understand
what to do when you learn of a security flaw. The simplest thing is to
quietly notify any of the major Linux or BSD distributions and let
them take it from there. For example here is how to
report to Red Hat, here
is how to report to Debian, here is FreeBSD.
Once you notify someone, wait to hear back. The upstream maintainer
would normally announce the vulnerability and commit patches to CVS at
the same coordinated time that vendors post packages. If you patch in
CVS before anyone is ready with packages, your users are vulnerable
during the gap (and generally unhappy about it). Worse, by committing
a patch to CVS you’re doing something that a black hat could notice,
but most sysadmins will not notice.
(This post was originally found at http://log.ometer.com/2005-05.html#22)