LWN: Comments on "Improving the handling of embargoed hardware-security bugs"

Improving the handling of embargoed hardware-security bugs

kmweber — Thu, 01 Nov 2018 22:17:20 +0000

> If a group of developers is talking to one hardware vendor, the other vendors will stay away from that group. That implies, he said, that the point of contact for each processor type needs to be the associated architecture maintainer.

Even this seems like it would break down on, e.g. x86(-64) vulnerabilities that are specific to Intel but not AMD (as AMD claims is the case with Foreshadow and Meltdown) or vice-versa, wouldn't it?

Improving the handling of embargoed hardware-security bugs

anton — Thu, 01 Nov 2018 17:31:01 +0000

A drawback of the embargo is patents: If the security researchers find the vulnerability on Intel, and therefore inform Intel, Intel can patent all the ways to fix the problem that they can think of. While, e.g., AMD has patent exchange agreements with Intel, a startup RISC-V manufacturer probably does not, and will find itself at a disadvantage thanks to the embargo.

Improving the handling of embargoed hardware-security bugs

brooksmoses — Thu, 01 Nov 2018 05:09:55 +0000

Adding to my other comment, note that "exploit is already in the wild" is a spectrum. There's "widely known and available in 'download it and run it' exploits", and there's "being hoarded by a few people as a zero-day to be deployed on one or two high-value targets".

Making a bug public is probably going to put it into the first of those categories in reasonably short order.

Meanwhile, if the exploit becomes widely known and being actively used at the script kiddie level while it's under embargo, it's likely that someone in the anti-attacker community is going to find out about it fairly quickly due to poor opsec on the part of some script kiddie, at which point the embargo is basically irrelevant.

So, effectively the tradeoff you get is something more like: Would you rather be aware of a known risk that every hack-script builder also knows about and you don't have a good fix for, or gamble that you're not going to be the target of this particular hack when it's used as a tightly-targeted zero-day?

Personally, I think if the latter is a serious concern to you, the precautions that you would have taken had you known about Meltdown before the embargo was lifted are pretty much precautions you should be taking regardless: Don't trust software you haven't completely vetted to run on your machine, don't trust any interface to be an impenetrable barrier unless you can (and do) audit the traffic, and assume timing data on that traffic is an exploitable side channel that you need to secure.

Improving the handling of embargoed hardware-security bugs

brooksmoses — Thu, 01 Nov 2018 04:47:21 +0000

Of course, the hypothesis is a bit more complicated than that.

It is very unlikely that the attackers gain will access to information about the vulnerability at the same time that the vendor does. If they already have this information at the point the vendor discovers it, then a delay from the vendor makes the situation only quantitatively worse, not qualitatively -- the time the attackers can exploit it gets longer due to the embargo, but it doesn't come into existence due to the embargo. If the embargo time is short compared to the length of time that the exploitable bug has existed, then it's unlikely that the embargo causes a substantial increase in the time the attackers can exploit it, and also unlikely that the attackers will discover it during the embargo period if they haven't already discovered it.

Meanwhile, you have to consider the value of lifting the embargo earlier. Lifting it early doesn't necessarily mean the end users are then "safe". If there are essentially no practical fixes without changes from the manufacturer, and the manufacturer doesn't have those changes ready, then lifting the embargo only helps attackers without helping users protect themselves. Even if there are practical fixes available, rushing them out before they are "fully baked" increases the risk that they are insufficient or buggy, at which point we can basically assume that the attackers will find the bugs in the patches before they can be patched, and that's almost as bad as lifting the embargo without a fix.

And, of course, there's also the observation that there are certainly plenty of "less skilled, less informed, slow, etc." attackers in the world -- and, once the embargo is lifted, they too can pretty quickly start exploiting the bug. So even if a few highly-skilled attackers already know of the bug, lifting the embargo without a reliable fix in place still has high cost.

Improving the handling of embargoed hardware-security bugs

ortalo — Mon, 29 Oct 2018 15:29:51 +0000

Well, primarily the manufacturers lawyers themselves, from everyone else lawyers, I guess.

That's not a trade off IMHO, more of an hypothesis coverage issue.
The implied hypothesis is that your attackers do not have access to the vulnerability information.
I hate this hypothesis because in some sense, it means you only consider attackers more stupid [1] than defenders.
Which in itself is contradictive. (Only stupid defenders do such an hypothesis, no? ;-)

[1] less skilled, less informed, slow, etc.

Improving the handling of embargoed hardware-security bugs

JoeBuck — Fri, 26 Oct 2018 17:22:21 +0000

Why do you think selective disclosure violates antitrust laws? What law do you think is violated?

The only related thing I can think of is the insider trading laws: if a hardware vendor selectively discloses a serious bug to a limited number of people, and any of those people trade the vendor's stock (sell their shares or short the stock, or even buy a competitor's stock) while the embargo is on that's a crime. But I don't think there are laws against favoring some customers over others.

Improving the handling of embargoed hardware-security bugs

nilsmeyer — Fri, 26 Oct 2018 08:21:36 +0000

"Please sign this legal document exposing you to liability so you can fix our mistake" is probably not the right approach.

I also wonder how selectively disclosing vulnerabilities to major cloud providers doesn't violate anti-trust laws.

Improving the handling of embargoed hardware-security bugs

excors — Thu, 25 Oct 2018 21:37:03 +0000

https://www.mips.com/blog/mips-response-on-speculative-ex... says P5600 and P6600 could be affected by Spectre (and a MIPS person submitted Spectre patches to LLVM for them, so presumably "could be" means "is"). But I don't know if the "old MIPS processors" refers to them (P6600 is only 3 years old) or other ones by architecture licensees.

Improving the handling of embargoed hardware-security bugs

mangix — Thu, 25 Oct 2018 21:08:06 +0000

Anyone have references for the MIPS comments? ImgTech claimed that MIPS processors don’t speculate deeply enough for meltdown and Spectre to be an issue. Has that changed?

Improving the handling of embargoed hardware-security bugs

hansendc — Thu, 25 Oct 2018 21:07:20 +0000

I wondered the same thing for software vendors. Surely they don't stop selling software while there's an embargo in place for a new security issue.

Improving the handling of embargoed hardware-security bugs

roc — Thu, 25 Oct 2018 20:05:26 +0000

> is anyone really more "secure" because a vulnerability isn't disclosed to the "public" for 6 months?

Surely the answer is "sometimes yes".

Tradeoffs are hard.

Improving the handling of embargoed hardware-security bugs

jhoblitt — Thu, 25 Oct 2018 19:45:40 +0000

Does a hardware vendor have any level of legal liability if they know of a *defect* and continue to sell defective components without disclosing it to the buyer? What about if the vendor is aware of a vulnerability and an end-user is victimized by the vulnerability?

I grasp that shipping a microcode update is unlikely to ever be an overnight process but is anyone really more "secure" because a vulnerability isn't disclosed to the "public" for 6 months? I think I'd rather be aware of a known risk rather than gamble that a exploit isn't already in the wild...