search

suit-wg / information-model

1 stars 1 forks source link

Security Consideration Clarifications #15

Closed hannestschofenig closed 3 years ago

hannestschofenig commented 3 years ago

Ben Kaduk wrote:

Section 4

We should probably mention the URI security considerations (RFC 3986) somewhere, as well as that remote resources need to receive an equal amount of cryptographic protection as the manifest itself, when dereferencing URIs.

We might also discuss the risks when a device believes that it possesses a source of secure time but the timesource is actually flawed.

It might also be worth reiterating the topic that came up during one of the other review threads: firmware update is by definition remote code execution, so if you trust an entity to provide your firmware, you are trusting them to do the right thing. Many classes of attack involving malicious or modified payloads then become irrelevant, so we are left with just needing to verify that it did come from a trusted party and is not going backwards, topics that are covered quite well already (including TOCTOU).

Section 4.2

A bit of intro for the format of each subsection might be helpful; e.g., the optional presence of the "Threat Escalation" portion took me some time to understand.

Section 4.2.9

If an attacker can install their firmware on a device, by manipulating either payload or metadata, then they have complete

This feels like an "e.g." kind of thing, with payload and metadata modification not necessarily being an exhaustive list of ways to get an attacker's firmware on a device.

Section 4.2.11.1

This is a denial of service because it can render devices inoperable. This is an elevation of privilege because it allows the attacker to make installation decisions that should be made by the Operator.

In this example it seems like the decision was supposed to have been made by the Network Operator specifically, but perhaps I misunderstand.

Section 4.5.9

systems. This requires the manifest to specify the digest of each statically linked dependency. In addition, the manifest format MUST

I don't understand how this follows. Aren't statically linked dependencies incorporated into the image itself, in which case knowing their individual digest values serve no purpose? (Also, "cryptographic digest" again.)

Section 4.5.12

The structure of the manifest MUST be simple to parse, without need for a general-purpose parser.

I'm not sure what constitutes a "general-purpose parser" for this purpose.

hannestschofenig commented 3 years ago

Mostly fixed with -10 version of the draft.