4

Originally, Meltdown and Spectre had a coordinated disclosure date of January 9, 2018. Some vendors were preparing to release fixes at that time, and were caught by surprise when the vulnaribilities were made public earlier (as described here, for example). But why were they made public ahead of time and where?

The earliest reference to these vulnerabilities I could find is in this article from the Register, published on the 2nd of January. But it does not mention any sources other than:

However, some details of the flaw have surfaced, and so this is what we know.

Do we know where these "details" have surfaced for the first time and why they were made public ahead of the coordinated disclosure date?

  • 1
    First I heard of it was Jan 1st. I think I read some earlier speculation, but it wasn't as clear. – CodesInChaos Jan 9 '18 at 18:27
  • First I saw of it was here early morning January 1st at 12:40 AM though it was just guess work from the patches (e.g., not in on the speculative execution). – dr jimbob Jan 9 '18 at 18:39
6

I followed the news of these attacks with a lot of interest starting on Jan 3rd, and have done some digging back to see what else people had been saying prior to disclosure.

The embargo was officially broken on Jan. 3rd by this post from Google, followed shortly by a bundle of technical details in their Project Zero post.

In that first link they justify breaking the embargo by saying: "We are posting before an originally coordinated disclosure date of January 9, 2018 because of existing public reports and growing speculation in the press and security research community about the issue, which raises the risk of exploitation."

There were a number of reports that an aware observer could have picked up on prior to that date. The biggest "smoking gun" for a speculative execution exploit (that I'm aware of) was made when an AMD developer submitted a Linux patch on Dec. 26th, which is linked in the article you provide. To my knowledge that's the first time a public report directly connected speculative memory references to a possible attack and patchset. Prior to this an article at LWN on Dec. 20th suggested that the page table isolation patchest was really addressing a deeper security flaw, but no specific reference to speculative execution being the source of the problem.

People really started to pay attention on Dec. 28th-29th after the page table isolation patches were merged into the kernel by Linus. A change of this magnitude usually takes a lot longer to be applied to the mainline kernel, so this essentially announced to the world that there was indeed an embargoed vulnerability.

The internet started blowing up on Dec 30th and Jan 1st. grsecurity on Twitter was convinced that there was an embargo at least as early as the 28th, and on the 30th observed to the world that there were missing source code comments in the Linux patchset. python sweetness on Tumblr accurately predicted on Jan 1st that it was a hardware-based vulnerability in x86 that could do unprivileged memory reads, and speculated about the possible hypervisor attack based on the presence of employees of Amazon and Google being looped in.

Then, of course, the Register published their piece on Jan 2nd and the entire world was looped in. That article referenced AMD's Dec 26th patch and connected speculative execution to the undisclosed vulnerability.

There has been growing interest in the security research community about the vulnerability of modern microarchitectures. The Spectre paper cites no less than 12 other works about leaking data from inside the processor or L1 cache, and recent work from 2016 about exploiting branch predictors to bypass address space randomization arguably laid the foundations for Spectre. Anders Fogh's blog outlined some basic techniques for the attacks at the end of last July but reported a negative result. If you throw Fogh in there, that's three separate groups independently finding and reporting these specific vulnerabilities inside a single year.

The Spectre vulnerability in particular is a really big deal, meaning that they're going to be talking about it for a long-long-long time to come. My guess is that part of the desire to disclose early was to make sure they claim credit where it was due. Imagine if you were sitting on a game-changing vulnerability. You know that at least one other group has already independently discovered your vulnerability, and if you're up to date on your blogs you know that Fogh has been investigating the same. A sudden bout of press activity spooks you into thinking that a fourth person has discovered and was about to disclose the same vulnerability you'd been sitting on for a year!

What specifically caused Google's team to break the embargo we won't know. The Register's article is the obvious candidate, but the cat was really out of the bag once the page table isolation patches started moving in early December.

3

The initial article from the register did not release exact details on how the exploits worked. The version you have linked lists several sources including the linux kernel mailing list, the linux source, Anders Fogh's blog (for an extremely similar issue).

At that point in time Linux patches were released publicly and emails relating to them were on the Linux Mailing lists.

The register could have picked up on either of these or been contacted by any one of a very large number of people in the corporations and open source organisations who were contacted within the embargo period.

Reason being embargoes are a two sided argument. During the embargo period you cannot be certain bad parties are not already exploiting the attack in the wild. Meanwhile you do know for certain there are large numbers of vulnerable parties who you have deliberately chosen not to let know so they can take steps to mitigate / reduce impact.

Or the skeptical view - someone offered to sell it to the register and they knew just how much advertising revenue would be huge.

  • 1
    Good point about the Linux patches. For example, there is a public discussion of the Linux patches in the comments of a German news article on Linux kernel news. There, someone points out (on 2017-12-31) that introducing a change as drastic as kernel page-table isolation (KPTI) in a pre-release kernel means there is probably some "spectacular publication" ("spektakuläre Veröffentlichung") around the corner. – sleske Jan 9 '18 at 10:30
  • 1
    In other words, the mere announcement of the changes to counter Meltdown and Spectre (by Linux, Microsoft and others) were enough to make people realize some big vulnerability was around the corner. That is a common problem with responsible disclosure - you can't patch without people wondering why you are patching... – sleske Jan 9 '18 at 10:32
  • @sleske - Microsoft has the added benefit of being closed source. They can patch with an obscure message only posting binary. For linux everything is in the public eye. – Hector Jan 9 '18 at 10:33
  • 2
    Yes, you're right in principle. However, in this case someone still noticed: Alex Ionescu, a Windows security expert, posted about a change in Windows 10 build 17035 on Twitter in November 2017. No idea how he knew, though. – sleske Jan 9 '18 at 10:46
  • 4
    @sleske - looks like he just reverse engineered the patch. Still - he viewed it as a security improvement and didn't speculate that it was in relation to an upcoming vulnerability disclosure. Because Microsoft is closed source you're less likely to - they could have been working on this for years. Meanwhile with Linux a big change like this just appearing in pre-release without heavy discussion is a major red flag. – Hector Jan 9 '18 at 11:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.