The future of vendor-sec

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 potential leak 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 remember."

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:

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 when 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.