Re: Summary of the current state of the tag2upload discussion
Aigars Mahinovs <aigarius@gmail.com> writes:
> On Sun, Jun 23, 2024, 19:17 Scott Kitterman <debian@kitterman.com> 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 (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: