Vulnerability: (x86_64) images are built with a pre-initialised (and thus common) pacman local signing key
I initially discovered and submitted an issue for the ARM image build process (manjaro-arm/applications/manjaro-arm-tools#33 (closed)), which has since been addressed by Dan Johansen (@Strit). However, upon further investigation, it was realised this issue affects x86_64 Manjaro installations also.
Manjaro x86_64 installations can be tricked into installing maliciously signed packages by a network attacker, leading to code execution as root.
CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H (7.1 High)
Manjaro ISO images, used for installation of Manjaro on x86_64 systems, contain pre-initialised pacman keyrings - i.e., the
/etc/pacman.d/gnupg directory. When a Manjaro system is installed, its
/etc/pacman.d/gnupg directory is inherited from the installation medium.
This is problematic because everyone who installs from these common installation mediums will inherit the same and non-secret local signing key (both private and public components). This is dangerous because the local signing key can be used to directly sign packages for installation via pacman - even those obtained from supposedly official mirrors.
I was able to confirm that a man-in-the-middle attacker (or a rogue mirror) can use the signing key extracted from a corresponding ISO image to serve modified databases and packages which would then appear authentic to pacman's signature checks and would thus be installed without any objection. As such, malware could be installed to a user's device by a man-in-the-middle attacker during an update or package installation.
(Note that, technically, databases don't need to be signed, but packages must be signed by a trusted key. The database typically contains package signatures, and so it probably needs to be modified by an attacker also.)
- Use of plaintext HTTP mirrors (i.e. not HTTPS) are still commonplace and enabled by default, allowing database and package downloads to be subverted by a network-adjacent attacker. Note, however, that a freshly installed Manjaro installation may not always be configured with an HTTP mirror - it involves a little chance as I understand.
- It's my understanding that Manjaro can be configured to download updates automatically. I'm not sure if it will install them automatically (as that's generally not sensible for Arch-based platforms), but poisoning the database/package cache may be 50% of the way there.
- I have only tested the
manjaro-gnome-21.0.4-minimal-210506-linux510.isoimage, but it's my understanding that the issue arises from the build process and that all images and Manjaro installations are likely affected.
- Different installation mediums are initialised with different keys. An attacker would need to use the local signing key from the specific installation medium used to install a system in order to attack it. Though, I suspect that an attacker could try multiple signatures at once if multiple packages are to be installed/upgraded.
/etc/pacman.d/gnupgshould be purged before the installation image is finalised.
Defer initialisation of the pacman keyring (
pacman-key --populate ...) until the installation medium is booted. Note that it's probably sufficient to inherit keys from the installation medium so long as the installation medium's keys are generated uniquely for each boot.
- Rebuild any affected images to exclude pre-initialised keyrings as soon as possible.
Retroactively revoke compromised local signing keys on affected hosts and individually regenerate the keyring from scratch, so that existing installations can be protected.
This list can be compiled from an archive of installation mediums.(Keyring regenerated if system version below
manjaro-gnome-21.0.4-210506-linux510.iso/manjaro/x86_64/rootfs.sfs/etc/pacman.d/gnupg/private-keys-v1.d/D10EEE9A774D88C46B3A7377E7DC6D84164E0959.key is copied as-is to systems installed from this medium.