unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Emacs package manager vulnerable to replay attacks
@ 2014-12-30 10:42 Kelly Dean
  2014-12-30 11:45 ` Ivan Shmakov
  0 siblings, 1 reply; 15+ messages in thread
From: Kelly Dean @ 2014-12-30 10:42 UTC (permalink / raw)
  To: emacs-devel

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.



^ permalink raw reply	[flat|nested] 15+ messages in thread
end of thread, other threads:[~2017-09-02 12:24 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <jwv4ms03cj3.fsf-monnier+emacsbugs@gnu.org>
     [not found] ` <quFzgVhBDz7zhUp0lS56OK32kQQjWsi4jSGZeullV6K@local>
     [not found]   ` <iKceXlDJbawOYczzAAZidbwV0Sq68CGaBNzyymlTMR2@local>
2015-01-09  6:59     ` bug#19479: Copyright issue (was: Re: bug#19479: Package manager vulnerable) Kelly Dean
2015-01-09 15:17       ` bug#19479: Copyright issue Stefan Monnier
2015-01-09 15:29         ` David Kastrup
2015-01-09 19:57         ` Kelly Dean
2015-01-09 20:24           ` bug#19479: " Glenn Morris
2015-01-09 20:32             ` Glenn Morris
     [not found]       ` <rt-3.4.5-910-1421783402-547.973211-5-0@rt.gnu.org>
     [not found]         ` <sXpSIlT9bkMLz7zWFLWTjm38mvYqlezH8vXlii5uxqC@local>
2015-02-24 18:11           ` bug#19479: Disclaimer is now on file at FSF Glenn Morris
2015-02-24 23:02             ` Kelly Dean
2015-02-25 21:09               ` Glenn Morris
2017-09-02 12:24                 ` Eli Zaretskii
2015-02-25  4:41             ` Vibhav Pant
2015-02-25  5:32               ` Stephen J. Turnbull
2014-12-30 10:42 Emacs package manager vulnerable to replay attacks Kelly Dean
2014-12-30 11:45 ` Ivan Shmakov
     [not found]   ` <F8kXGdneKQWh6B82cOwdrCdBAdO1h3o9WXOqLmHuB8T@local>
     [not found]     ` <iHwGTo6KPGu52f1tOLq6Ek7KcZ7r2tufrT1z4GnPndF@local>
2015-02-24  8:47       ` Kelly Dean

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).