Russ Allbery <r...@debian.org> writes: > The decision on whether to adopt tag2upload should be made primarily on > non-security grounds.
Generally I reach the same conclusion, although I think there are real security problems with both the existing and the proposed tag2upload mechanism that we should all be aware of. It is acceptable to realize that we cannot protect against all attacks with reasonable costs. That's why we need the ability to transparently audit all steps, to detect them when they occur. Reversely: it would be unfortunate to say no to new functionality because the new functionality don't solve all possible problems. That just stalls progress. > ## Threat model > > I evaluated both the existing source package upload architecture and the > tag2upload architecture against the following threats: > > - Someone not in the keyring uploads a malicious source package, possibly > via a sponsor. > > - Someone in the keyring (either a Debian Developer or a Debian Maintainer > for a package) uploads a malicious source package but makes it appear > that the package was uploaded by someone else in the keyring. > > - An attacker compromises the system a Debian uploader uses to build > source packages and uses that access to inject malicious code into a > source package. > > - Someone with administrative access to the archive processing machinery > (DAK, the archive signing key, or similar infrastructure) uploads a > malicious source package. > > - Someone with administrative access to the tag2upload server or its > signing key uploads a malicious source package. > > - Someone with administrative access to Salsa uploads a malicious source > package. Having a threat model is great. I find the notion of "uploads a source package" is poorly defined here though. What threat model of those (if any) cover the situation were someone in the keyring uploads a (benign) source package and something on Debian's side (e.g., design of tag2upload) enables an attacker to substitute some part of the intended upload with something malicious? With tag2upload, I don't think we can reasonable talk about "upload a source package" any more. What would you define that to actually mean? Maybe I'm missing some introductionary documentation here. > ### Git object collisions > > The current Git repository format and wire protocols use SHA-1 hash > digests (and only SHA-1 hash digests) to identify objects in the Git > repository. Git uses a SHA-1 hash function that has been > [hardened against the SHAttered attack on > SHA-1](https://github.com/cr-marcstevens/sha1collisiondetection), > and therefore is probably not vulnerable to known collision attacks. Can this be substantiated? Using SHA1CD in Git does not necessarily mean someone cannot manually create a Git repository with a colliding git commit somewhere in the history that gets accepted by git, and allows someone to replace actual file contents. That may be the case, but I haven't seen any detailed analysis answering that. > This analysis is relevant only for SHA-1-based Git repositories. Once > Salsa supports SHA-256 Git repositories, tag2upload could decline to act > on any repository that uses SHA-1 hash digests, making this entire section > moot. I don't think it will be as simple as that: the git SHA256 transition documents suggests to me that even signed tags may refer to both SHA256 and SHA1 commits: https://git-scm.com/docs/hash-function-transition#_signed_tags Thus tag2upload would need to require 1) SHA256 Git repository support, AND 2) that git tags refer to a SHA256 commit id, AND 3) any git submodules used also rely on SHA256 rather than SHA1. > #### Replacing the upstream tree > > The attack: Construct a benign and malicious Git tree pair containing only > the upstream source. Reference the benign tree in a source package and get > that source package signed by a sponsor to trigger tag2upload processing. > Race the tag2upload server by deleting the upstream tag and commit ID and > then pushing the malicious Git repository as a new commit with the same > commit ID. I think this is an important and realistic attack vector that we shouldn't be vulnerable to. > The upstream tag name is present in the signed tag metadata, but since > that tag itself is not required to be signed, the attacker can move it at > will. The upstream tag therefore provides no protection against this > attack apart from a small detection risk. Authentication of the upstream > tree comes only from the inclusion of its commit ID in the tag metadata. Which is SHA1 currently, and thus vulnerable to a collision attack, which are known to be possible. > I suspect (but am not certain) that this attack would normally be > prevented by the Salsa Git service. The benign tree already existed in the > same repository with the referenced commit ID (presumed to be checked by > the sponsor during review), and even if references to that object are > deleted via branch deletion, I believe Git will reject the push of the > malicious commit ID until the old objects have been garbage-collected. > This presumably will take long enough that the tag2upload process will > fail because the upstream commit is missing. > > This attack could be done by someone with administrative access to Salsa, > and thus in a position to force an immediate garbage collection of the > unreferenced objects so that the tree underlying the upstream commit ID > can be replaced. Administrative access to Salsa would also make it trivial > to win the race against the tag2upload server. This attack is less prone > to detection than moving the tag to a different Salsa repository. > > There is a variation on this attack where the attacker deletes the Git tag > and tree that it references, pushes a colliding tree, and then repushes > the Git tag. I believe this has essentially the same properties as the > above attack. Is Salsa admin access necessary? Isn't 'Maintainer' access sufficient? To me, the protection against this attack seems weak, and I don't really see any strong protection against it. Couldn't we require that the signed tag2upload tag comment contains a hash of the upstream code, somehow? > ### Second-preimage attacks > > An attacker could attempt to take the signature from a tag2upload tag > pushed to an arbitrary repository on Salsa and apply that same signature > to a Git tag for a malicious package on Salsa with the same version > number, triggering the tag2upload process. However, this requires > constructing a malicious repository with the same SHA-1 hash digest as the > repository containing the original tag. This is a second-preimage attack > on SHA-1, which is believed to be currently infeasible. (Second-preimage > attacks are believed to be currently infeasible even against MD5, which is > a much weaker hash function.) tag2upload therefore prevents this attack. > > This same attack is could be tried against the existing upload mechanism > by attempting to reuse the signature of an upload changes control file > published in the > [debian-devel-changes list > archive](https://lists.debian.org/debian-devel-changes/). > The second-preimage resistance of the hash function used by the OpenPGP > signature similarly prevents this attack. Is a second preimage really required to mount this attack? Consider if someone creates a collision for a good and a bad version, gets the good version signed by a sponsor, and then re-use that signature for the bad version. /Simon
signature.asc
Description: PGP signature
