How long should security embargoes be?

Security embargoes are something of a double-edged sword. The idea is to coordinate a release date for a particular security fix between the affected parties (typically distributions in the Linux world). But, while the embargo is in place, no fixes are being issued which increases the length of time that users are vulnerable. That could lead to widespread—or targeted—attacks against vulnerable systems if the flaw is already known, is leaked, or is rediscovered during the embargo period. The chances of that may be relatively small, but they certainly increase as a function of the length of the embargo.

It is for those reasons that embargoes in the Linux world are typically short. While proprietary vendors will sometimes sit on a vulnerability for months, Linux embargoes are generally on the order of a week or two. The rules for the acceptable length of an embargo are set by the venue where the information is shared, which for Linux distributions is the closed linux-distros mailing list. There is also an associated distros mailing list which also adds in representatives from some of the BSDs. These two lists have taken the place of the vendor-sec list that was compromised in March 2011.

Up until recently, the guidelines for linux-distros specified that the maximum allowable embargo was 14 days. That means that anyone reporting a bug to the list should be willing to wait that long to publicly release any information; it also binds list participants to that deadline. The idea is that anyone who doesn't want to agree to embargoes of up to 14 days shouldn't be using linux-distros. As part of the discussion of the bug and fix on that list, a coordinated release date (CRD) would be chosen so that all distributions would release at the end of the embargo period.

List administrator Alexander Peslyak (aka Solar Designer) recently made a change to the guidelines to better reflect reality. There is an effort to avoid having a CRD that falls on a Monday or a Friday to try to not land on a holiday or other inconvenient day for administrators who may need to do lots of updates because of the security fix. That meant that the 14 day maximum sometimes stretched to 19 days, so Peslyak changed the page to reflect that. He also posted to the open oss-security list to highlight the change.

There were no complaints about the change, though there were some alternatives suggested (10 business days for example), until Peslyak followed up his message suggesting that perhaps the 14-19 days be reduced to 7-11 days. Even that length of time is longer than he would like, "but I am proposing what I think has a chance to be approved by others without making the list a lot less useful to them".

Peslyak also outlined his reasons for preferring shorter embargo windows. Distributions that have the fix ready more quickly can get it into the hands of users sooner, rather than waiting a week or more for the embargo to end. Also, it reduces the window of time in which the vulnerability could be rediscovered or leaked from the list somehow. There are also logistical concerns with longer embargoes including increased tracking of multiple overlapping embargoes.

Both Marc Deslauriers of the Ubuntu security team and Kurt Seifried of the Red Hat security response team were quick to disagree with a one-week (more or less) embargo period. Depending on the severity of the bug and the difficulty of the fix, it may be hard for some distributions to pull together, test, and release fixes in that time frame. In particular, Seifried is concerned about volunteer-run distributions that may lack the staff to ensure fixes in a shorter period. But Deslauriers makes another important point:

That's the fine line that Peslyak is walking here. If the embargo requirements become too onerous (or seem that way), distributions may stop reporting to the list—or only report after they have made progress with a fix. But, other lists have other rules. The closed kernel security list says that it will do embargoes up to 7 days, but it seems to rarely happen that way, undoubtedly partially due to Linus Torvalds's distaste for embargoes. That policy may also result in distributions delaying reports to the kernel security list, of course.

It should be noted that these "closed" lists have been fairly leaky at times. In addition to the vendor-sec list compromise, the kernel security list may have been breached as part of the kernel.org compromise. The linux-distros list now uses PGP-encrypted emails, which should help unless the host doing the re-encryption to each member's key is breached.

There are also dangers from fixes that are rushed, of course. The recent PHP remote code execution vulnerability came about because of a rushed fix for a different security hole. There is certainly value in taking some time to get a security fix right, the only question here is how long that should be, and, for full disclosure types, whether users should be made aware of the problem while the fix is in progress.

In the end, the 14-19 day window stayed, though a preference for embargoes of less than 7 days was added. It's a difficult problem, partly because there are so many unknowns. Fixes can be difficult to apply (particularly if they need to be backported) and to test, especially for multiple distribution releases. But the longer the bug is embargoed, the longer users are at risk without any ability to mitigate the problem locally while awaiting a fix. That's why the full disclosure camp believes that information on security holes should be released without delay, so that users are empowered to make their own decisions. That approach is not very popular with vendors, of course. Embargoes and their length is an issue that will likely be debated again and again because there isn't an "obviously correct" solution.