CVE-2018-5390 and "embargoes"

A kernel bug that allows a remote denial of service via crafted packets was fixed recently and the resulting patch was merged on July 23. But an announcement of the flaw (which is CVE-2018-5390) was not released until August 6—a two-week window where users were left in the dark. It was not just the patch that might have alerted attackers; the flaw was publicized in other ways, as well, before the announcement, which has led to some discussion of embargo policies on the oss-security mailing list. Within free-software circles, embargoes are generally seen as a necessary evil, but delaying the disclosure of an already-public bug does not sit well.

The bug itself, which Red Hat calls SegmentSmack, gives a way for a remote attacker to cause the CPU to spend all of its time reassembling packets from out-of-order segments. Sending tiny crafted TCP segments with random offsets in an ongoing session would cause the out-of-order queue to fill; processing that queue could saturate the CPU. According to Red Hat, a small amount of traffic (e.g. 2kbps) could cause the condition but, importantly, it cannot be done using spoofed IP addresses, so filtering may be effective, which may blunt the impact somewhat.

The "semi-embargo" for CVE-2018-5390 came about because CERT was apparently coordinating with Linux distributions (and with FreeBSD on a separate flaw that was reported at the same time). But a tweet by grsecurity highlighted the flaw on July 23; that was followed up with another tweet on July 28 when stable kernels incorporating the fix were released. Matthew Garrett eventually alerted the oss-security mailing list about the bug on August 8. The closed distros and linux-distros mailing lists were used to coordinate the response; those lists have a requirement that, once the bug is made public, the original reporter should post about it to oss-security.

Garrett's post was fairly light on details, which didn't sit well with Stiepan A. Kovac. He asked for more information and seemed to threaten some sort of lawsuit against the "opaque Linux-distros vulnerability-disclosure-among-friends-for-fun-and-profit scheme". While Alexander Peslyak (better known as "Solar Designer"), who founded and moderates all of these security mailing lists (oss-security, distros, linux-distros), agreed that more details were needed and that Kovac's complaint about the semi-embargo raised a real issue, he did think the "focus on legal aspects" was unfortunate. He described the timeline of the bug disclosure as follows:

Peslyak is not happy about how that all played out. For one thing, the distros lists are meant to be used only for non-public vulnerabilities. The public fix and subsequent tweet publicized the bug fairly widely, which meant that it should not have been handled in "secret" on those lists:

He speculated on the reasons why the reporting of the bug may have languished, but he also was not pleased with the two-day delay getting any information to oss-security:

Garrett apologized for the delay in posting to oss-security (which presumably means he was the one that brought the issue to the distros lists) and for the lack of additional information. Peslyak and others did ensure that those details were posted, however. While the distros lists have a long list of policies and procedures for participants and reporters, it seems clear that this particular bug went its own way—potentially to the detriment of Linux users.

Peslyak speculated that the original bug reporter, Juha-Matti Tilli of Aalto University, Department of Communications and Networking, and Nokia Bell Labs, was also involved in the decision-making on the disclosure of the bug, which may have slowed things down. In addition, the semi-related FreeBSD bug (CVE-2018-6922) got into the mix since it was reported at the same time. However, it was apparently known to the participants in the distros thread(s) that the issue was, at least partly, public; that would have allowed the bug to be exploited by black hats, while leaving most of the rest of the community out in the cold. It would not be surprising to see future public "non-public" bugs be treated quite differently; it seems unlikely that Peslyak would allow this kind of situation to happen again.

Embargoes are meant to be short, at least in the free-software world. As Intel found out with the Spectre and Meltdown disclosure mess, a poorly organized, long embargo is likely to lead to leaks. It should be noted that the L1TF vulnerabilities that were announced on August 14 had been reported to Intel in early January; that too is a long time to keep a secret, but apparently lessons were learned and this set of bug fixes went more smoothly than the last. Hardware flaws affecting multiple operating systems, cloud providers, and others are likely to require a longer coordination period, but the longer flaws are hidden—and the number of people "in the know" increases—the more likely premature disclosure is.

In the case of CVE-2018-5390, though, we don't exactly have a case of premature disclosure. The bug was plainly fixed in full view (and that fix was highlighted by a well-known security researcher). There is little to be gained—and much to be lost—by "hiding" the vulnerability at that point. The horse is loose, so the state of the barn door is immaterial.