This message from a while back was still in my queue to respond to, and since I was updating my security review anyway, I wanted to think through it a bit more. I think I understand what Sam is getting at.
Sam Hartman <hartm...@debian.org> writes: > Sorry I was assuming that the web ui and the git repository were still > consistent, but were inconsistent with what was uploaded to the > archive. > I.E. > t =0 attacker uploads something undesirable through tag2upload. > t=1 attacker convinces salsa and dgit to replace that git tree with a > tree that is not undesirable and that has the same hash (so signatures > still verify). > If you look at git, everything looks fine. > If you clone git or dgit, everything looks fine. > If you look at the archive you still see the undesirable code. I see, thank you! A Git hash collision is sufficient to perform this attack on Salsa. I do not believe a Git hash collision gets an attacker far enough to perform this attack on the dgit-repos server unless the dgit-repos server is also compromised. This is where it's append-only nature helps considerably. Even if there is a hash collision, the first instance of that hash pushed to the server will win. Subsequent pushes of an object with the same hash will be ignored because the server already has that hash. Unlike with Salsa, there is no way to delete the references to that object and force it to be pruned so that a different object can be pushed. I therefore believe it's not possible to perform the object substitution attack that attacks via hash collisions rely on unless the server is compromised and the attacker can delete or replace objects. *If* one verifies the signature on the Git tag, I'm not sure how one can perform an attack like this without a Git hash collision, a compromise of the OpenPGP signing protocol or signature algorithm, or some similar cryptographic attack. A more interesting case is if people do this investigation without verifying the Git tag signature. That step is vital in the case of a Debian infrastructure compromise. If the personal credentials of someone with general Debian infrastructure access, and therefore administrative access to all of dak, tag2upload, Salsa, and dgit-repos, are compromised, the attacker is then in a position to invent a whole new view of the archive with whatever properties that they wish. At that point, our last line of defense is uploader Git signatures, whether over the source package (the current case) or Git tags (the tag2upload case). One interesting fine point here is that the tool that retrieves the Git tag and corresponding Git tree from dgit-repos to verify it should use transfer.fsckObjects to ensure the integrity of the resulting Git tree. This protects against some types of compromise of the dgit-repos server. I *think* this scenario is reasonably well-covered in the current draft of my security review, which emphasizes that checking the signature on the Git tag is necessary to detect several attacks that involve compromise of the tag2upload server. It is of course possible that there will be some new comprehensive attack on Git tags or on OpenPGP signatures that we haven't anticipated. > However, I think your comment about tag2upload not making this worse may > still apply. > In particular, today it's obvious that I don't need to upload sources > that differ from what I push to salsa (if I do not use dgit). Right, the tracing we have today, for packages that don't use dgit, is entirely ad hoc and may not be possible at all. > The only way in which tag2upload really comes into play is that it > increases dgit use and increases the probability that people will assume > looking at salsa|dgit is the same as looking at the archive. > And as we've discussed here, that may or may not be true. Yes, this is also a good point. If people rely on dgit-repos to be an accurate reflection of the archive, a compromise of the dgit-repos server allows the attacker to deceive people about the archive contents. Reproducible source builds detect a wide variety of these attacks, particularly if they are ongoing (in other words, not just on initial upload, but periodically pulling all the source packages in the archive and reproducing them again). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
