Compromise of local repository in threat model

[Zach Wasserman]

Hi All,

We've built an updater implementation using go-tuf (https://github.com/fleetdm/fleet/blob/main/ee/fleetctl/updates.go, https://github.com/fleetdm/fleet/blob/main/orbit/pkg/update/update.go) and have had it reviewed from a security perspective.

One of the findings seems to suggest a threat model in which the local copy of the repository (where the targets are staged) may be compromised independently of the keys used locally for the signing.

From the report:

> If Fleet updates commands are executed from a malicious repository, then an attacker may force the user to read and sign his files, effectively compromising keys. That's because the user has no way to establish a root of trust - he lacks knowledge about the root public key.

> The fleetctl updates add and fleetctl updates timestamp commands open the repository located in the current working directory or specified by the --path argument. They do not verify signatures of files in the repository. So an attacker with write access to the files - but without access to the private keys - can write arbitrary content to the files and these will be signed by the Fleet user. To protect against such attacks, the fleetctl may require users to provide a root public key e.g, as the command line parameter and use it to verify content of the repository prior to updating it.

> The fleetctl updates roots command, which prints the root public key, could be additionally protected by out-of-band verification of its output. For example, users should be instructed to compute a hash of the printed public key and compare it with the expected root key ID, e.g. the one printed after repository initialization. If a repository initialization takes place after a long time from the roots command execution, users should be asked to securely store the ID, e.g. in their password manager or in a file with restricted access. To enable users to correctly compute an ID from a printed public key, default json encoder used in the updatesRootsFunc function should be replaced with the github.com/tent/canonical-json-go encoder used by the go-tuf library - see figure 5.1.

> Exploit Scenario: Attacker gets access to a local repository. He replaces the hash of the orbit binary in the targets.json file and waits. The Fleet user stages updates for the osqueryd binary - replaces the old binary with a new one, updates hashes and other data in repository files, and signs them. Signed target.json file contains the correct hash of the osqueryd, but an incorrect, attacker controlled hash of the orbit. After that, the attacker replaces the orbit file with his malware and waits until the Fleet user publishes the updated repository.

As far as I can tell, the TUF specification does not include a threat model in which the local copy of the repository may be compromised. Should it? Or is sufficient to recommend that the local repository be protected by being stored offline and only attached when signing operations take place?

Thank you for any insights,

Zach Wasserman

[Justin Cappos]

So my two cents on this is that you are largely right that a copy of the files to be signed should be stored carefully offline, with the relevant key (a target's role key in your example).  

However, the defenders can also check the diff when copying files over to the repository.  If an unexpected file has changed, this is evidence of an attack.  (We describe a similar scenario in the Diplomat paper, when talking about how to recover from a compromise.)

I hope this helps.  We can clarify more if needed.

--
You received this message because you are subscribed to the Google Groups "The Update Framework (TUF)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to theupdateframew...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/theupdateframework/4e154aee-f9fd-403a-9776-031f55877dben%40googlegroups.com.

[Zach Wasserman]

Thank you for the clarification on this. Seems like we can indicate that the threat model does not include protecting the repository files and those are intended to be protected along with the key.

[Jussi Kukkonen]

Just dug this thread from the spam folder so I'm a bit late to the discussion, apologies. I saw your conclusion:

    the threat model does not include protecting the repository files and those are intended to be protected along with the key.

I wanted to point out that what you described so far sounds like an implementation design issue and that as far as I can see the TUF security model does not​ break if target files or metadata files get compromised on the "server". However, this only applies from the moment metadata gets signed and requires your repository code to actually check the signatures on metadata. From your description ("[attacker] replaces the hash of the orbit binary in the targets.json file") it sounds like you have unsigned metadata stored on disk or you are resigning without checking the existing signature. Creating unsigned metadata in one process and only signing it in a separate, later process obviously creates a window of opportunity that signatures cannot protect from. 

In my opinion one of the insightful things about the TUF design is the separation of targets keys and the "online" keys: this gives an implementer the possibility to solve two issues that would otherwise conflict:

• targets metadata can be signed with targets keys as soon as new target files come out of the build pipeline. Targets keys are in control of the target builders
  
• the repository / distribution machinery can do their own decision on whether to include the new targets metadata in a snapshot and when to do it. The "online" snapshot/timestamp keys are available to a snapshot process (separate from the target build process) and are controlled by repository maintainers

So from a clients perspective the results of a server side compromise should be roughly:

• target files compromised on server: denial of service at worst
• metadata compromised on server: denial of service at worst
• online keys compromised: denial of service, freeze attacks
• targets keys compromised: arbitrary files served (assuming snapshot process does not prevent it)

I'm not saying implementing a server in a way that is resilient against compromised local metadata is trivial: there's absolutely a lot of details to handle that the spec does not spell out (and can't spell out because many details will be implementation specific) but as far as I can tell this is completely possible.

Hope that helps,

Jussi

---

From: theupdate...@googlegroups.com <theupdate...@googlegroups.com> on behalf of Zach Wasserman <za...@fleetdm.com>
Sent: Monday, 16 August 2021 3.33
To: The Update Framework (TUF) <theupdate...@googlegroups.com>
Subject: [Suspected Spam] [tuf] Compromise of local repository in threat model