Improving the handling of embargoed hardware-security bugs [LWN.net]

Improving the handling of embargoed hardware-security bugs

Posted Oct 25, 2018 19:45 UTC (Thu) by jhoblitt (subscriber, #77733)
Parent article: Improving the handling of embargoed hardware-security bugs

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

to post comments

Improving the handling of embargoed hardware-security bugs

Posted Oct 25, 2018 20:05 UTC (Thu) by roc (subscriber, #30627) [Link] (3 responses)

> 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

Posted Oct 29, 2018 15:29 UTC (Mon) by ortalo (guest, #4654) [Link] (2 responses)

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

Posted Nov 1, 2018 4:47 UTC (Thu) by brooksmoses (guest, #88422) [Link] (1 responses)

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

Posted Nov 1, 2018 17:31 UTC (Thu) by anton (subscriber, #25547) [Link]

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

Posted Oct 25, 2018 21:07 UTC (Thu) by hansendc (subscriber, #7363) [Link]

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

Posted Nov 1, 2018 5:09 UTC (Thu) by brooksmoses (guest, #88422) [Link]

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.