20

In the last decade side-channel attacks like fault injection attacks (e.g., voltage glitching attacks) have been used to bypass JTAG locks or read-out memory protections. Such vulnerabilities might not be easy to prevent. They can be caused by the hardware design or by the firmware in use. Therefore, in order to fix such vulnerabilities, vendors might need to change hardware design of their products so that the vulnerability cannot be easily fixed in customer products without replacing the component.

Is such a thing as "responsible disclosure" even possible, given that fixing such a vulnerability might need a hardware redesign and a replacement of components?

Would it therefore not be unethical to release any public information after 90 days?

3
  • 4
    In your specific examples this applies less, or this would be an answer: It's worth bearing in mind that hardware was designed by someone. It being unpatchable was, in itself, a security failure, and well-designed systems can be updated -- if nothing else, to turn insecure features entirely off. Companies are more than happy to do this when they want to seek more rent by licensing access to hardware you bought; it's wrong to assume they can't do it for security. (Plus, hardware rarely acts alone; e.g. an insecure chip peripheral can usually be disabled, firewalls can filter traffic, etc.)
    – anon
    Apr 23, 2023 at 19:52
  • 6
    An example of this type of situation - Nintendo Switches released before ~ mid 2018 are vulnerable to exploits allowing you to get root on the device, without any hardware modifications, due to a design oversight (or just not expecting it to be found, possibly). The people who discovered this did alert Nintendo, and wait 90 days before the public release, even though it was probably understood even at the time to be unfixable. Apr 24, 2023 at 16:24
  • 1
    @Clockwork-Muse To be fair a local exploit to root a closed device is a very different kind of vulnerability; many argue it is beneficial for the device owner. Apr 25, 2023 at 11:09

4 Answers 4

28

The idea of a responsible disclosure is to protect the customers both in the short term and the long term. What this exactly means in terms of disclosure timelines and details depends on how severe the vulnerability is, how fast it can be fixed and how fast the fixes can be rolled out by the customers. There is no single approach to responsible disclosure which works for all cases.

In the long term it is good if the affected products get fixed or at least newer products don't have the same vulnerability. This might take longer with hardware based vulnerabilities than with purely software. For fixing the problem the manufacturer needs to know the problem, so disclosing it to the manufacturer is a good thing. If it is a more generic vulnerability affecting multiple manufacturers or even standards, then it needs an even wider disclosure.

But customers need to protect themselves in the short term already. For this they might not need all the details about the vulnerability or even working exploits, but customers need enough details to determine their risks and mitigate them. How this mitigation will be done with vulnerabilities in the hardware depends on how the product is used by the customer, i.e. it might mean to add better physical protection around the product or in the worst case stop using the product completely.

4
  • 1
    Thanks for your answer! This covers the customer side very well and I agree with everything you wrote. Let's assume the vulnerability can only be fixed by replacing the hardware (so its not a firmware issue). Would publicly disclosing such a vulnerability harm the vendor more comparted to a pure SW vulnerability? A SW vulnerability could be easily fixed in field, the hw vulnerability needs a replacement which means much higher costs and therefore possibly affects the vendors reputiation in a negative way. Should such a vulnerability therefore disclosed to the vendor only and not publicly?
    – dudekowsky
    Apr 24, 2023 at 8:20
  • 6
    @dudekowsky: Always assume that other might find the same vulnerability (and maybe have already). So it is always necessary to inform the customers with enough details, so that they can mitigate the risk. Vendor reputation should be irrelevant here. Apr 24, 2023 at 10:30
  • 2
    @dudekowsky: FTFY -- "possibly affects the vendors reputation in a negative-but-completely-deserved way"
    – Ben Voigt
    Apr 24, 2023 at 22:43
  • 5
    @dudekowsky protecting the vendors reputation (and share price) is not one of the goals of responsible disclosure. The full and responsible disclosure movements largely came about because of companies who were more concerned about trying to protect their reputation than they were about securing their products.
    – Gh0stFish
    Apr 25, 2023 at 14:44
13

to bypass JTAG locks or read-out memory protection

In most cases, this only poses risk of exposing manufacturer's own intellectual property. Code read-out protection is not the only way to protect that, they can also e.g. monitor whether clone products appear on market and litigate.

For some specific cases, like a hardware password manager or crypto wallet, debugger access could expose user's data to an attacker with physical access. In that case a responsible disclosure would give enough time for manufacturer to alert customers about the risk, even if no fix is possible.

The debugger access also enables further security analysis that can discover security problems in the firmware. But typically those are software bugs that can be fixed with a firmware update, following a normal disclosure process.

1

Hardware vulnerabilities rarely have a proper fix short of replacing the affected hardware. Often a firmware mitigation is possible which merely disables the vulnerable hardware feature, which inherently creates a conflict of interest: users would like to keep the affected feature if they deem the vulnerability is not affecting them, while manufacturers would rather protect themselves from liability and/or protect their own IP. Note that the lion's share of such vulnerabilities are essentially failed restriction measures the manufacturer has put in place to prevent the user from getting access to certain features, such as debug interfaces.

Disclosing the vulnerability to the manufacturer before making it public can therefore put customers at disadvantage, preventing them from taking measures (such as disabling firmware updates or avoiding official repair services) that would preserve the functionality they need.

1
  • 1
    That is an interesting point, thank you!
    – dudekowsky
    Apr 26, 2023 at 18:08
0

Everything Steffan said, and more. Specifically, in "customers need enough details to determine their risks and mitigate them", mitigate includes even things like "throw away the affected devices and go back to a non-electronic process" or "change physical security practices so that the vulnerability is no longer attack surface".

I would go so far as to say that, for hardware based vulnerabilities, the default "responsible disclosure", short of a specific reason otherwise, should be "immediate full disclosure". Unlike with software, there is no way vendors can deliver a timely fix to everyone affected, so there is utterly no benefit to the affected parties (users/customers and people they are protecting) if you give the vendor early notice.

2
  • 1
    I don't really agree with your second paragraph. Hardware vulnerabilities often have software or firmware mitigations; and even if not, vendors may be able to deliver timely mitigations to particularly sensitive customers (e.g. cloud services providers, who in turn have many customers that might be affected). I'm sure it's sometimes the case that there's no benefit in giving the vendor advance notice, but it takes a lot of confidence (arrogance?) to decide on your own that there's no way a vendor could possibly do anything beneficial that you haven't thought of.
    – ruakh
    Apr 26, 2023 at 2:28
  • @ruakh: It takes confidence/arrogance? No, just experience/knowledge of history. Apr 26, 2023 at 14:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .