Security: deb-s3 incorporates existing release/manifests without verifying signatures

[eriksw]

When performing operations such as uploading a package, deb-s3 fetches existing manifest and release files and trusts them fully without verifying that they are signed by a trusted key. This allows for the security provided by apt repository signing to be defeated:

1. Adversary with ability to write to the bucket but without the signing key uploads a malicious package(s) and updated but unsigned manifest/release files that incorporate the malicious package(s).
2. When the authorized deb-s3 user (who has the signing key) performs any operation where deb-s3 updates the manifests/release, the malicious package(s) become incorporated into a validly signed release.

The entire point of apt repository signing is to prevent malicious tampering with the repository by an adversary that as a given does have the ability to modify the repository at rest but does not have any trusted signing keys.

By failing to verify that information retrieved from the bucket has not been tampered with before incorporating that information into updated manifest/release files that are signed with a trusted key, deb-s3 creates an opportunity for malicious packages to be distributed as if the adversary had control of a trusted signing key.

[tomelliff]

Why are you allowing untrusted users write access to your S3 buckets?

[eriksw]

@tomelliff Ideally, that would of course never happen. However, at-rest compromise of package repositories(/mirrors) does happen, that's a part of why the ability for signing to happen offline is a feature of most robust update/distribution schemes.

The issue here is that deb-s3 undermines that by blindly trusting the at-rest repo, treating the signature as just a thing to be done so that clients trust the repo instead of as part of keeping the repo itself secure.