[advisory]
id = "HSEC-2023-0015"
cwe = [672]
keywords = ["hackage", "mitm", "supply-chain"]

[[affected]]
package = "cabal-install"
cvss = "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N"
[[affected.versions]]
introduced = "1.24.0.0"
fixed = "3.10.2.0"

[[references]]
type = "REPORT"
url = "https://github.com/haskell/cabal/issues/8918#issuecomment-1521096581"
[[references]]
type = "FIX"
url = "https://github.com/haskell/cabal/commit/dcfdc9cffd74cade4e8cf3df37c5993413ffd30f"

cabal-install uses expired key policies

A problem was recently discovered in cabal-install's implementation of the Hackage Security protocol that would allow an attacker who was in possession of a revoked private key and who could perform a man-in-the-middle attack against Hackage to use the revoked key to deliver malicious packages. At this time, this is only a theoretical attack - no keys have been revoked. Release 3.10.2.0 of cabal-install contains a fix for this bug, and we have contacted distributors of older versions (such as Linux distributions) with a patch that they can apply.

Background

Hackage Security is an implementation of The Update Framework, which is a design for a package repository that allows untrusted mirrors without undermining software supply-chain security. In particular, Hackage Security cryptographically guarantees the following properties:

• Mirrors of Hackage cannot change the contents of packages. This prevents the insertion of malicious code.

• Mirrors cannot omit newer packages for more than a few days without clients noticing. This ensures both that mirrors cannot maliciously deny security updates, and that mistakes in their configuration will be noticed.

Hackage has a key policy file that delegates authority to a number of private keys for various purposes. Most of the keys are kept securely offline by trusted community members who annually re-sign the various files to indicate that they still have confidence in Hackage's policies. However, to prevent clients from being denied updates, Hackage has an automated process that periodically re-signs a timestamp file. This signature has a short expiry. Additionally, a snapshot file contains signed hashes of the Hackage index that is updated on each package upload. The timestamp and snapshot private keys are held in memory on the Hackage server. These are called the operational keys. If an operational key is ever compromised, then it will be revoked by having the Hackage root keyholders sign a new key policy file. To prevent replay attacks, clients that connect to Hackage after this update will reject older policy files, based on a monotonically increasing file version number.

If a client has not yet received the updated policy file (for example, because they have a fresh install of cabal-install or because they have not run cabal update in some time), the built-in expiration date in the file limits the window of exposure in which the revoked operational keys would be expected. As long as the root keys have not been compromised, the compromised operational keys can only be used until the policy file expires. In addition to compromising a Hackage operational key, an attacker would additionally need to either compromise a Hackage mirror or perform a man-in-the-middle attack against the target in order to serve a malicious or obsolete package index.

The Issue

A bug in cabal-install caused it to skip the verification of the key policy file's expiration timestamp. This means that users of older, unpatched versions of cabal-install could be vulnerable to a malicious mirror or man-in-the-middle attack against Hackage if they have not connected to Hackage in a long time, even after the policy file has expired.

We do not believe that it has been possible to exploit this vulnerability, because no operational keys have been revoked. However, in case key revocation occurs, we strongly advise all users of cabal-install to ensure that they have version 3.10.2.0 or newer, which contain the fix.