Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Issue If an attacker is able to control a threshold of keys to insert the same public key more than once with different key IDs into signed, trusted metadata on a TUF repository, then go-tuf clients < 0.3.2 are susceptible to an attack where attackers can cause the same signature from the same public key to be counted more than once against the threshold of signatures because they were mistakenly distinguished due to having different key IDs. For example, suppose that in the root metadata file, there were a threshold of 2 self-signatures required from 2 different keys $KA$ and $KB$ belonging to Alice and Bob respectively. Bob has either mistakenly or maliciously produced a signed a malicious version of the root metadata file where Alice's key is listed once with the keyid $SHA2{256}(KA)$, but his public key is listed twice, once with the keyid $SHA2{256}(KB)$, and the other with $SHA2{512}(KB)$. If Bob can convince Alice to mistakenly sign this root metadata file without noticing…
Recommended action: Upgrade to 0.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact go-tuf does not correctly implement the client workflow for updating the metadata files for roles other than the root role. Specifically, checks for rollback attacks are not implemented correctly meaning an attacker can cause clients to install software that is older than the software which the client previously knew to be available, and may include software with known vulnerabilities. In more detail, the client code of go-tuf has several issues in regards to preventing rollback attacks: 1. It does not take into account the content of any previously trusted metadata, if available, before proceeding with updating roles other than the root role (i.e., steps 5.4.3.1 and 5.5.5 of the detailed client workflow). This means that any form of version verification done on the newly-downloaded metadata is made using the default value of zero, which always passes. 1. For both timestamp and snapshot roles, go-tuf saves these metadata files as trusted before verifying if the version of the…
Recommended action: Upgrade to 0.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.