Aigars Mahinovs <[email protected]> writes: > On Sun, Jun 23, 2024, 19:17 Scott Kitterman <[email protected]> wrote:
>> As an example, I think the fact that I can download any source package >> in the archive and cryptographically verify who uploaded it and that >> it's unmodified from what was uploaded is an important property of our >> current archive structure. IIRC, you've claimed it's not. I don't >> think either of us has a very good understanding of why the other >> believes that. I think for both of us it's just too obviously true/not >> true to be easy to explain. > There are a few problems with that. [snip a lot of things that I agree with] I worked on an update of my security review last night to take into account the additional concerns that people have raised and other feedback. I wrote a whole bunch of words about this specifically because I don't think it's too obvious to explain at all, and my opinion is more nuanced than simply saying this archive property isn't important. From a security standpoint, I care about attacks and defenses, and care about abstract properties to the extent that they are useful in preventing attacks. Here's what I came up with (this hasn't been published yet; it's still a draft). #### Misattribution of the source package Determining who uploaded a source package given only the signed source package becomes slightly more complex in the tag2upload design. If the package is not signed by the tag2upload key, the signer is the uploader, as with the current system. If it is signed by the tag2upload key, the uploader can be extracted from additional fields in the `*.dsc` file. That uploader information is trustworthy provided that the tag2upload key has not been compromised and the tag2upload service was not compromised at the time this source package was constructed. In both the current and the tag2upload case, a compromise of the source package build allows upload of malicious code, but compromise of the tag2upload service additionally allows superficial misattribution of that upload to any uploader the attacker chooses. It's not clear that this is useful for the attacker. If anyone checks the signed Git tag referenced by the source package metadata and discovers it either doesn't exist or is signed by someone other than the source package claims, they will immediately detect the compromise of the tag2upload service, which is generally not to the attacker's advantage. In most cases, injecting malicious code into the source package without modifying the attribution is a safer attack strategy. However, this misattribution could be used to try to hide from casual inspection packages synthesized entirely on the tag2upload server that never had a corresponding signed Git tag. If the archive processing software were modified to extract the attributed uploader from the source package metadata and email upload notifications to them as well as the maintainer, this would make detection of misattributed source packages much more likely. If the archive processing software were modified to accept an additional file in tag2upload uploads containing the signed Git tag, it could check that the tag2upload attribution matches the signed tag. This effectively prevents this attack except in the case where the archive processing software is also compromised, which is discussed in the next section. ### Archive processing Someone with administrative access to the archive processing machinery, including the archive signing key, could inject a malicious source or binary package into the archive. This is not prevented by either the current upload architecture or by tag2upload. This attack on source packages can be detected by verifying the signatures on all of the source packages in the archive. This remains true after the introduction of tag2upload; some of those source packages will be signed by the tag2upload key instead of a maintainer key, but neither of those keys are available to the archive processing machinery and are therefore equivalent when detecting this specific attack. Compromise of both archive processing and the tag2upload service or key would allow injection of source packages signed with the tag2upload key that could not be detected by this method or by reproducible binary builds. Verifying the Git tag references in source packages uploaded by tag2upload against the corresponding Git tags archived on the dgit-repos server would detect this combined attack. This attack therefore remains easier to detect than injecting malicious code into binary packages, which only requires compromising archive processing and which can only be systematically detected by reproducible binary builds. The best detection strategy against a combined compromise of archive processing and the tag2upload service, and many other attacks on source packages in both the current and tag2upload cases, is to create an independent service that reproduces the source package construction done by tag2upload from the original signed Git tag and compares the results to the source package as published in the archive. ### Source package signatures Currently, the source packages present in the archive include OpenPGP signatures on the `*.dsc` file from the original uploader. For packages uploaded by tag2upload, the `*.dsc` file will instead be signed by the tag2upload service key, and the original uploader, their key fingerprint, and a reference to the original signed Git tag will be added as additional Debian source package control fields in the `*.dsc` file. Understanding the security implications of this change requires some analysis. The source package signature can be used for three purposes: 1. Detect modifications to the source package after it was uploaded. 2. Determine who uploaded this source package. 3. Verify that the source package repesents the intent of the uploader. For the first purpose, the primary protection against archive modifications is the sources list file, signed by the archive key, which contains hashes of all of the source package files. This case is therefore only interesting if the archive processing software or database has been compromised, if the source package is retrieved from the archive without checking its hashes against the sources list, or if the source package is being checked outside of the context of the archive. The implications of a compromise of the archive processing software are discussed above. Verification that the package has not been modified, when outside of the context of the archive, depends on the security of the tag2upload service and its key. This is true of any signed source package outside of the context of the archive: verification that it has not been modified depends entirely on the security of the key that has signed it. However, the tag2upload service and key can be abused to generate far more source packages without arousing suspicion than the typical uploader key, since the tag2upload key is expected to sign a variety of source packages. The second purpose is discussed above in the context of compromises of the tag2upload server. For the third purpose, I believe only weak intent information can be derived from the uploader signature today. It is common practice in Debian to verify the Git tree that one wants to upload, run a package build step, and then blindly sign the resulting source package. The uploader signature therefore does not say that the uploader verified the correctness of the source package, only that they triggered a build process and trusted its results. This is equivalent in the tag2upload case except that the uploader signature happens before the build process (on the Git tag) rather than after the build process (on the source package). In both cases, the uploader does not subsequently verify the content of the source package; in both cases, if the system on which the source package is built is compromised, the source package may be compromised and the uploader signature step will not detect this compromise. Therefore, for this purpose, the current uploader signature appears to provide stronger evidence of intent than it truly does. The signature on the original Git tag triggering the upload provides equal evidence of uploader intent. There is one remaining difference: in the current upload case, the OpenPGP signature of the uploader is published in the archive. In the tag2upload design as reviewed, the uploader's OpenPGP signature (in the form of the signed Git tag) is published to the dgit-repos server but not in the archive. This could be changed if desired by, for example, tag2upload providing and the archive processing software accepting and publishing an additional file accompanying the source package containing the original signed Git tag. In conclusion, the source package signatures present in the archive cannot be used to detect manipulation of source packages following a compromise of the tag2upload server in two specific cases: - Detection of tampering with the source package outside of the context of the archive, or without checking the archive sources list. - Detection of a package created on the tag2upload server without an accompanying signed Git tag, if the verification software does not retrieve and verify the signed Git tag referenced by the source package metadata. The second problem can be fixed with the archive processing software modification discussed under "Misattribution of the source package." A tool that, given a tag2upload-signed source package, retrieved the corresponding Git tag, verified the signature, and compared its metadata to the source package metadata would also fix the second problem if it were used whenever verifying source packages outside of the archive. If that tool additionally reconstructed the source package based on that tag and compared its contents to the source package published in the archive, it would provide a stronger guarantee for all three purposes than either the current upload mechanism or the current tag2upload design provides. It is worth noting for comparison purposes that a compromise of a binary buildd is even harder to detect, since it leaves no trace in the archive at all apart from the malicious binary package. -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
