Emacs package manager vulnerable to replay attacks

["Kelly Dean" <kelly@prtime.org>]

Remove your ~/.emacs.d/elpa/ directory, and start 24.4.
Use the default of '(("gnu" . "http://elpa.gnu.org/packages/")) for package-archives.
Do M-x list-packages, which will download the archive metadata (http://elpa.gnu.org/packages/archive-contents and its sig file), verify the sig, and generate archive-contents.signed which indicates successful verification.
Then:
mkdir /tmp/localarch; cd /tmp/localarch
cp ~/.emacs.d/elpa/archives/gnu/* . # archive-contents and archive-contents.signed
wget http://elpa.gnu.org/packages/undo-tree-0.6.5.el # Currently latest in elpa
wget http://elpa.gnu.org/packages/undo-tree-0.6.5.el.sig

Now in Emacs, do (setq package-archives '(("gnu" . "/tmp/localarch/")))

Undo-tree 0.6.7 doesn't exist yet, but let's pretend that it does, and it fixes a hypothetical security vulnerability in 0.6.5, and the update has been uploaded to elpa. (Skipping 0.6.6 for this example since it does exist, just not in elpa.)

To simulate this, edit /tmp/localarch/archive-contents, find the entry for undo-tree, and change the (0 6 5) to (0 6 7). Your modified file will no longer verify with http://elpa.gnu.org/packages/archive-contents.sig, but that's ok since you already have /tmp/localarch/archive-contents.signed.

Now, to simulate a package replay attack, rename undo-tree-0.6.5.el to undo-tree-0.6.7.el, and undo-tree-0.6.5.el.sig to undo-tree-0.6.7.el.sig. Then do M-x list-packages again, then install undo-tree 0.6.7. It installs successfully, meaning you've tricked Emacs into installing the vulnerable version of the package even though archive-contents lists the fixed version.

For a live attack, first retrieve all packages and their sig files from elpa, then wait for a vulnerability to be discovered and fixed in one of them, e.g. undo-tree 0.6.5.
Allow your victim to run list-packages to download the new archive-contents (which lists the fixed undo-tree 0.6.7) and to verify it using the new archive-contents.sig.
Then when he tries to download undo-tree-0.6.7.el and undo-tree-0.6.7.el.sig, intercept his connection and give him the content of undo-tree-0.6.5.el and undo-tree-0.6.5.el.sig, so that his Emacs saves the old content using the new names.

His Emacs will successfully verify the signature because it is authentic; you retrieved authentic (but now stale) packages and signatures in your first step. His Emacs will then install the stale package because the version number embedded in the filename matches the version number specified in the new archive-contents file.

The attack also works for already-installed packages when new versions are published; you can deliver stale data when the victim tries to upgrade.

To solve the problem above, simply include a hash of the package content in the package's record in archive-contents, rather than only including the package name and version number in that file as Emacs currently does. This solution also happens to make per-package signatures from the elpa key superfluous, so you can remove that feature from Emacs and remove those signature files from elpa for the sake of simplicity, and use the elpa key only to sign the archive-contents file.
(Of course, per-commit (not just per-package) signatures from authors would still be useful, so that users don't have to trust the elpa keyholder alone, but that's a separate issue. Emacs should barf if a package hash doesn't verify, regardless of whether any signatures verify.)

Package replay attacks could be prevented without putting hashes in archive-contents, by instead verifying that the version number listed in archive-contents matches the version number listed in the package itself, if version numbers were never reused for different versions of packages. But there is at least one package (undo-tree) that does re-use version numbers, so hashes are still necessary. Hashes also prevent elpa itself from reusing version numbers; forcing elpa to issue a new archive-contents whenever it lists a new version of any package makes it more conspicuous that something changed, and making the historical record clear closes off one particular method of attack if the elpa key is compromised.

After the problem of package replay attacks is solved, you can still attack by replaying not only packages, but also the metadata (i.e. the archive-contents and archive-contents.sig files). To solve this problem, include a timestamp of archive-contents in that file itself (so that the signature depends on the timestamp), and have Emacs ignore any new archive-contents that's older than the latest valid one that Emacs has already seen or is older than some specified limit (IIRC Debian's apt-get uses a 10-day limit).

For details on replay attacks, see the 2008 publication
https://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html

Another attack is the endless-data attack; I haven't checked whether Emacs is vulnerable. See
https://www.cs.arizona.edu/stork/packagemanagersecurity/otherattacks.html
But since Emacs signs its repository metadata, it appears it is not vulnerable to any of the other attacks described on that page.

In addition to recording hashes, also record the length of the content; it's convenient for early detection of endless-data attacks and of misconfigurations.

One final feature that isn't necessary for preventing any of the vulnerabilities above, but still is helpful to make the historical record even more clear, is to include in each version of archive-contents a hash (and length) of the previous version of that file. This further constrains an attacker who has compromised the elpa key; he can still launch attacks, but it's harder to keep the attacks secret for very long, since he's forced to cause a fork in what's supposed to be a linear hash chain.

Fortunately, all four of these features (package hashes, content length, archive timestamps, and archive hash chaining) are straightforward to implement.