Vulnerability - no repo_gpgcheck on Fedora repos

Ask Fedora
,
1

Can someone pitch in to explain if F40 and below users are prone to MTM attacks if they use unsecured http to download Fedora repo metadata?

Sounds like someone can swap out some package data and user will download a compromised package that will pass per package gpg checks (since signature data can be swapped out by an attacker).

Will this vulnerability be mitigated if we just use https for syncing repos?

I saw F41 had some critical issues with implementing repo_gpgcheck on dnf5 and that it was not working before and that it is not working on version 4 dnf. Why does dnf give GPG signature verification errors for repos with repo_gpgcheck=1?

2

Can you please elaborate on how this would be possible?

Each rpm package is signed with a gpg signature that dnf will check and compare with the expected signature. IMHO, that is a pretty safe process, so http is sufficient.

3

This is not a critical issue, it’s rather an annoyance. Didn’t fully read the topic but it seems that the GPG key wasn’t installed and thus dnf refused to install packages. So, actually expected behaviour.
The bug was since fixed: repo: fix bad GPG error handling by evan-goode · Pull Request #2138 · rpm-software-management/dnf5 · GitHub

4

Someone in the middle (man-in-the-middle) can simulate fedora repo with a modified package over unsecured http, since there’s no GPG check over the repo data. That package will include a different GPG key for the modified package, so GPG check for the individual package will pass.

I was told this is not fixed for dnf version 4 (they don’t even provide a repo GPG key for Fedora repos)..

5

The package signatures have to match the keys stored in /etc/pki/rpm-gpg/
The repo data only uses checksum to verify the package

6

so, if you change any bit in the package, the checksum would change and not match the expected one… dnf won’t install the package

7

Each package is security signed before it’s uploaded to the repo

$ rpm -qi cinnamon  bash  gjs |grep Signature
Signature   : RSA/SHA256, Wed 26 Feb 2025 16:55:01 GMT, Key ID c8ac4916105ef944
Signature   : RSA/SHA256, Fri 08 Nov 2024 08:56:24 GMT, Key ID c8ac4916105ef944
Signature   : RSA/SHA256, Thu 16 Jan 2025 22:21:16 GMT, Key ID c8ac4916105ef944

$ gpg -v /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-42-primary
gpg: enabled compatibility flags:
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
gpg: using pgp trust model
pub   rsa4096 2024-02-12 [SCE]
      B0F4950458F69E1150C6C5EDC8AC4916105EF944
uid           Fedora (42) <fedora-42-primary@fedoraproject.org>
sig        C8AC4916105EF944 2024-02-12   [selfsig]
8

Ok, what’s the point of a repo GPG then?

9

There’s use cases for it for sure. If people sync the entire repo elsewhere it’s a way for people to tell that the repodata hasn’t been tampered with.

For people who don’t sign packages, repodata is a way to ensure that the packages aren’t tampered with (because the repodata has checksums).

It depends on your use case.

1 Like