HSEC-2023-0015: cabal-install uses expired key policy

Author: frasertweedale

advisories/hackage/cabal-install/HSEC-2023-0015.md

@@ -0,0 +1,95 @@
+```toml
+[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"
+```
+
+# Summary
+
+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.
+
+[key policy file]: https://hackage.haskell.org/root.json
+[The Update Framework]: https://theupdateframework.io/
+
+# 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.