There is a certain amount of irony in the news that the vendor-sec
mailing list—along with the server that distributes it—was
compromised. Vendor-sec is the closed mailing list that is used by
developers of Linux distributions along with members of the BSD development
community ("vendors" by some definition) to discuss
security problems before they are made public. So a compromise of
the mailing list could easily lead to security issues made "public" well
before fixes were available—an attacker's dream scenario.
How exactly the server was compromised is not clear, but a short time
after the announcement of the server
compromise and closing the backdoor that was being used, the attacker
returned. Vendor-sec moderator Marcus Meissner reported some five hours later that
"the attacker read this [the announcement]
and reentered the lst.de machine, went amok and destroyed the machine's
installation. The machine has now been shutdown.". The break-in
was noticed a week or so before the announcement, which seems like somewhat
tardy notice to those who might be posting to vendor-sec, but, worse yet,
the best guess for when the original break-in occurred is January
20—more than a month earlier.
During that time—possibly longer—the attacker could have been
reading the "secret" traffic on the list. Vendor-sec is nominally used to
coordinate response between the participants, and to embargo information
about the vulnerabilities until all are ready with a fix. Obviously, an
embargo is not likely to be observed by an attacker. But it's certainly
not at all clear that vendor-sec was leakproof prior to the break-in.
According to Meissner's announcement, there are 80-100 people signed up for
vendor-sec, so expecting that there are no leaks may be overly optimistic.
Even if all of the participants maintain the secrecy, though, the messages
were sent in the clear so they could be intercepted along the way, dug out
of inboxes by system administrators, or snagged from unattended mail
clients. Since at least January 20, of course, someone didn't even need to
do any of those, which started Meissner thinking about whether a closed
list like vendor-sec is even really needed any more, and if it is, what
changes might need to be made. So he threw that out for discussion.
The consensus seems to be that there is value in the closed list, but that
leaks should probably be expected—hopefully not from attackers, but
via list members by mistake, inattention, or, possibly,
malfeasance. Meissner has asked Alexander Peslyak (aka Solar Designer), who runs the
oss-security list and is the leader of the Openwall Linux
distribution, to take over vendor-sec, and part of that might mean that the
messages start being encrypted with GPG. That would stop some of the
sources, but obviously not all. But there were also questions about
whether the list should be split up and, if so, how.
Solar Designer suggested splitting the list
up into three different lists, one each for Linux, BSD, and security
researchers. The idea would be that subscribers would get less mail that
isn't relevant to their interest area, but others thought that was
unnecessarily complicating things. As Eugene Teo put it: "I think it is more
effective to have just one mailing list like before that everyone can
There is discussion of having oCERT (Open Source Computer Emergency
Response Team) host a vendor-sec-style mailing list. oCERT already has
verified contacts that could be used to disseminate non-public security
information to various projects as needed. Andrea Barisani, oCERT project
coordinator is open to such an arrangement,
though it would likely require more team members to handle the
workload. It could turn into a lot of additional work as Barisani describes:
This is a simplified approach compared to what we do now, which is contacting
project maintainers first, negotiating embargo as well as requesting a patch
that we can verify and relay to vendors, spread the patch to affected parties
along with embargo information and coordinate disclosure. This is a
time-consuming process that worked very well with oCERT because the number of
reports was limited, it helped solving complex bugs or vulnerabilities that
affected a large number of projects.
I think we can continue to do this for selected cases but it would be hard to
scale enough to support this "tailored" approach for every single report if
we expand our visibility, additionally I think everyone would favour less
extra process as pointed out already.
So far, no real decisions have been made. Some kind of vendor-sec list
seems to be useful, but whether it stays a single list, and where and how
it will be hosted are up in the air. Even though few are arguing that
vendor-sec should go away, there was some interesting data from Mark J. Cox about the
trends of reports to vendor-sec. Over time, it would seem that the number
of issues being reported first to vendor-sec have dropped significantly.
Cox keeps track of how the Red Hat security team first finds out about
vulnerabilities, and the data suggests that the importance of vendor-sec
for that purpose is diminishing. In 2008, 69 issues were found first on
vendor-sec, but by 2010
that had dropped to 29. According to Cox, 29 represents just 4% of the
total number of vulnerabilities fixed. In addition, the severity level of
those problems first reported to vendor-sec were not as high as some expected: "Of the flaws we rated impact critical or with a
CVSS [Common Vulnerability Scoring System] of 'high', only 4 were from that 29 from vendor-sec."
There may come a time when vendor-sec (or whatever it becomes) is no longer
needed, but we seemingly haven't reached that point yet. There are times
coordinating a fix (and establishing a CRD, coordinated release date) is
important to protect end-users from severe, non-public vulnerabilities.
While "full disclosure" is preferred by some, others are sold on "responsible
disclosure"; as long as that's the case, lists like vendor-sec will need to
be available to help orchestrate those releases.
to post comments)