On Wed, 12 Jun 2024 at 13:03:04 -0400, Antoine Beaupré wrote:
> On 2024-06-11 18:39:04, Russ Allbery wrote:
> > - 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.
...
> > Neither the existing upload mechanism nor tag2upload attempt to prevent or
> > detect (as opposed to trace) the upload of a malicious source package by
> > someone in full possession of a key in the keyring, so this threat is not
> > considered in this document, although tracing for this threat is
> > discussed briefly.
>
> I'm actually curious as to why that is treated as a separate
> possibility, because if kind of overlaps with the second model ("someone
> uploads a malicious package appearing from someone else")...
Using "victim" as a shorter name for the "someone else" that the attacker
wants to blame for the upload:
For the "makes it appear that..." scenario, the upload would have the
victim's name in all of its non-cryptographic metadata (debian/changelog,
git tag GIT_COMMITTER_NAME, etc.), but it would have to be signed by
the attacker's key - because the threat model in this scenario is that
the attacker's own private key is the only one in the keyring that they
have access to, so they can't sign it with the victim's key, or with
some third developer's key.
(Or I suppose the attacker could also generate a new keypair under their
control and sign with that, but it seems fairly obvious that it would
be rejected, because tag2upload wouldn't find it in the keyring -
hopefully there is a test-case for that!)
For the "full possession of a key" scenario, the threat model is that the
attacker *would* have access to the victim's private key, and therefore a
rational attacker would validly sign the upload with that, making it
indistinguishable from a legitimate upload by the victim (except for the
fact that, afterwards, the victim would hopefully say "wait, I didn't
upload that?" and start raising the alarm).
I think that's the intended difference here?
> For me, that case and the "xz-utils" case are actually quite pressing
> matters
The bottom line is that if the attacker has the victim's private key
material, then the attacker can do anything that the victim can do,
because in our key-based security model the only way we can authenticate
the victim remotely is that they have control of their own private key(s),
and the attacker (we assume) doesn't.
smcv
