Open-source software vs. the proposed Cyber Resilience Act (NLnet Labs)

Posted Nov 15, 2022 14:41 UTC (Tue) by farnz (subscriber, #17727)
In reply to: Open-source software vs. the proposed Cyber Resilience Act (NLnet Labs) by Vipketsh
Parent article: Open-source software vs. the proposed Cyber Resilience Act (NLnet Labs)

Issuing a notice of conformity for a product or component carries liability with it if the notice is inaccurate. If the security assessment is done badly, and as a result the product or component does not actually meet the security standards you've claimed it meets, then you are liable to anyone in the EU who's affected by the deficiency.

And there's already ways to handle this within EU acquis if a product is built from components - the person issuing the notice of conformity for the product is liable until they demonstrate that the non-conformity is because a component is non-compliant. At that point, the entity that issued the notice of conformity for the component is responsible.

This isn't exactly an unusual process in industry - the EU adopted the whole "notice of conformity" thing from large company supply chains, because entities like the IEEE, IET and others already had this process set up for the standards they issued, complete with proforma conformance documents you can use to indicate how compliant you actually are with the standard.

Open-source software vs. the proposed Cyber Resilience Act (NLnet Labs)

Posted Nov 15, 2022 16:15 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (11 responses)

Who would have been liable for Spectre? By now, they would probably be bankrupt, given the sheer number of systems affected...

Open-source software vs. the proposed Cyber Resilience Act (NLnet Labs)

Posted Nov 15, 2022 16:50 UTC (Tue) by farnz (subscriber, #17727) [Link] (8 responses)

Ultimately, Intel for Intel's affected chips, Qualcomm for Qualcomm's affected chips etc.

And because they'd be sold as components, and not as final products, to get to liability, you'd have to show that if the component had conformed with the specification, then the product would not have had the non-conformance it actually had. So, for example, while I know that a former employer's product uses Spectre-afflicted chips, there should be no software running on it not supplied by my former employer, and thus there's no non-conformance of the final product (in turn, meaning that the non-conformance of the component is not a liability issue, since there's nothing to be liable for).

Open-source software vs. the proposed Cyber Resilience Act (NLnet Labs)

Posted Nov 15, 2022 17:27 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (7 responses)

Pre-Spectre, nobody would have thought to include "is not vulnerable to speculative execution side-channels" in the specification, because nobody realized that such side-channels existed in the first place. No component of the system would have violated any specification (assuming that the technical people are actually reading the specifications, anyway), but the system as a whole would still be vulnerable to attack. So again I ask: Who is liable for that?

Open-source software vs. the proposed Cyber Resilience Act (NLnet Labs)

Posted Nov 15, 2022 17:58 UTC (Tue) by deater (subscriber, #11746) [Link] (3 responses)

> because nobody realized that such side-channels existed in the first place

I can assure you people knew and were aware of the side-channel attacks. Especially people in government 3-letter agencies but also security researchers in general. The chip companies pushed ahead anyway because they thought the attacks were too difficult to exploit, but it turns out they were wrong.

Open-source software vs. the proposed Cyber Resilience Act (NLnet Labs)

Posted Nov 15, 2022 18:44 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (1 responses)

That's quite surprising to me. I mean, I imagine that the three-letter agencies knew about it, but I had no idea that "security researchers in general" were aware of it before the vulnerability was reported (circa 2017). Can you provide a citation that this was public knowledge before 2017?

Open-source software vs. the proposed Cyber Resilience Act (NLnet Labs)

Posted Nov 17, 2022 8:28 UTC (Thu) by anton (subscriber, #25547) [Link]

deater is doing the usual trick of writing about a different thing than you do: He writes about side-channel attacks in general (which I was taught about as a student in the 1980s, and for which the way we deal with them is to write software that deals with secret keys in a special way), you talk about speculative side-channel attacks (which were discovered in 2017, and for which the mitigation mentioned above is insufficient).

My guess this lack of differentiation is also why the hardware manufacturers are not fixing Spectre: Software has been mitigating or lived with side channel attacks forever, so we (hardware manufacturers) don't need to fix Spectre. And yes, it's possible to fix Spectre at a tiny cost in performance and a modest cost in silicon; and yes, it's now over five years since Intel and AMD learned about Spectre, so they could have fixed it in their new cores in the meantime.

Concerning conformance statements, Intel etc. probably would not have signed a statement that claims freedom from side channel attacks, and if they explicitly mentioned that side channels exist, they would probably be legally in the clear wrt. Spectre. Now if the manufacturer of a device with an Intel CPU employed the classic mitigation techniques, and claimed that it does not reveal secret keys, but may reveal other data through side channels, the first claim would be false in the light of Spectre. I guess the statement would contain some language about "state of the art", which would indemnify them, though.

After Spectre was revealed to the public, such conformance claims would become more interesting, though.

Open-source software vs. the proposed Cyber Resilience Act (NLnet Labs)

Posted Nov 17, 2022 12:23 UTC (Thu) by davecb (subscriber, #1574) [Link]

Side channels were discussed in the Bell-LaPadula era, around 1985. This particular implementation was not.

Open-source software vs. the proposed Cyber Resilience Act (NLnet Labs)

Posted Nov 15, 2022 21:26 UTC (Tue) by farnz (subscriber, #17727) [Link] (2 responses)

But that's not the sort of thing that goes into the specification; the specification for a CPU will say things like "a process running in user mode cannot access data that does not have a page table entry permitting user mode access to that data". Spectre's trick was bypassing that separation; if my device is now insecure, because I can bypass the separate to exfiltrate a secret, then Intel's on the hook. If, on the other hand, my device does not run software that could exfiltrate secrets (e.g. because it's a locked down appliance), Intel's fine - there's no non-conformance of the final device, and thus the fact that a component is non-conformant is not a problem.

Open-source software vs. the proposed Cyber Resilience Act (NLnet Labs)

Posted Nov 17, 2022 8:43 UTC (Thu) by anton (subscriber, #25547) [Link] (1 responses)

What you describe sounds like Meltdown, not Spectre.

A number of people have claimed that because there is MMU-based memory protection, that's the only protection that counts. I.e., that all the work people have been doing on avoiding buffer overflows in various ways does not count, because it's not enforced by the MMU, and therefore the CPU is free to reveal all the memory that a process has access to to an attacker.

But I have not seen any such specification in the architecture manuals I have looked at. Instead, the describe branch instructions in an architectural way. Microarchitectural things like branch prediction and caches are only described in optimization manuals, and are not supposed to change any architectural guarantees. One might argue that architectural guarantees just are about behaviour, not security, but that would mean that all these architectures give no security guarantee. Even the MMU does not give any guarantee that the Intel CPU does not switch to system management mode (SMM) between any two instructions, send the contents of all registers, all RAM, and all drives to the NSA, and then continue the execution where it left off. that describe the architectural effects of a branch, and load statements

Open-source software vs. the proposed Cyber Resilience Act (NLnet Labs)

Posted Nov 17, 2022 11:44 UTC (Thu) by farnz (subscriber, #17727) [Link]

This leads to a really important point; a fault in a component is not necessarily enough to invalidate the notice of conformity for an entire device.

For example, if I sell a home router that includes a Spectre-vulnerable CPU, but the security guarantees of the router (as included in its notice of conformity) are met because the router does not run externally provided code, and the noise in the network timing overwhelms side channel noise from the supplied code, then there's no liability, even though the component might not meet its notice of conformity as sent to the router manufacturer - the final device still meets its notice of conformity despite the CPU fault.

And it's entirely possible that commercially, device manufacturers will find themselves without risk-free combinations of components; a CPU may, in its notice of conformity, not guarantee any means to completely separate different processes running on the CPU, while an OS may make security guarantees that only hold if the CPU guarantees a means to separate different processes. It's then up to the device manufacturer to decide whether or not they are willing to take the risk on the CPU functioning as promised, or whether they're going to find insurance against the risk, or whether they simply give up on selling such a device inside the UE.

Open-source software vs. the proposed Cyber Resilience Act (NLnet Labs)

Posted Nov 15, 2022 18:36 UTC (Tue) by mfuzzey (subscriber, #57966) [Link]

A vulnerability isn't a problem by itself. It becomes a problem when the system context allows it to be exploited.

So spectre is a huge deal for cloud providers whose whole business model is renting compute capacity on the same hardware to multiple mutually untrusted customers.
But on an embedded device that only runs software provided by the manufacturer it's not really an issue.

I hope this law allows manufacturers to say "yes we know the hardware / software has vulnerabilities A,B,C but in our case that doesn't matter because of X,Y,Z

Open-source software vs. the proposed Cyber Resilience Act (NLnet Labs)

Posted Nov 15, 2022 20:29 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Since it was a completely new vulnerability, Intel would have probably been partially off the hook.

Liable for _fixing_ the consequences once the defects were discovered? Manufacturers of covered devices, who probably would get some money from Intel.