package.el downloads unsigned code over HTTP and executes it

[Dave Pifke]

This bug may be a little controversial, in that it's not really Ubuntu's problem, but I strongly believe that this is a security vulnerability that can (and should) be addressed.

Before emacs 24.4, package.el did not do any verification of downloaded packages. The very first TODO item in the source says as much:

  ;;; ToDo:

  ;; - a trust mechanism, since compiling a package can run arbitrary code.
  ;; For example, download package signatures and check that they match.

The single package repository configured is ELPA, over HTTP:

  (defcustom package-archives '(("gnu" . "http://elpa.gnu.org/packages/"))
     "An alist of archives from which to fetch. ...

While some elisp packages (e.g. org-mode) have been Debianized, many aren't, and most of the online guides for new Emacs users recommend using M-x package-install instead of the OS's native package manager. For elisp packages with lots of dependencies, it's a non-trivial effort to convert them to .deb packages.

Emacs 24.4 introduced a GPG-based package signing mechanism. It appears that most (all?) packages on ELPA now have .sig files. However, it will be over a year from now before emacs 24.4 hits an Ubuntu LTS release.

Off hand, I can think of three possible ways Ubuntu could address this:

1. Change http:// to https:// in the default configuration, since it appears that elpa.gnu.org is accessible over TLS. I do not yet know whether or not emacs will complain if the certificate does not chain back to a trusted CA root.

2. Backport package.el from Emacs 24.4 to Emacs 24.3. I do not yet know how much effort is involved.

3. Patch the shipped package.el to warn the user that they're doing something incredibly insecure and give them a chance to change their mind before code is downloaded, installed, and executed.

The situation is even more ridiculous if the user adds repositories such as MELPA, which automatically downloads code off of a anonymously-editable wiki(!!!) and serves it up to the user. See https://github.com/milkypostman/melpa/issues/2342. Unlike just running package-install on a vanilla emacs24 installation, however, I think it's a little easier to blame the user in that case, since they would have had to explicitly added the insecure package repository to their configuration.

This is perhaps as much a policy issue as a technical one. I would be happy to put together a proposed patch for any of the above options, depending on which path the ubuntu-security team thinks is best.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: emacs24 24.3+1-2ubuntu1
ProcVersionSignature: Ubuntu 3.13.0-45.74-generic 3.13.11-ckt13
Uname: Linux 3.13.0-45-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.6
Architecture: amd64
Date: Sun Feb 22 13:40:05 2015
InstallationDate: Installed on 2014-09-12 (163 days ago)
InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2)
SourcePackage: emacs24
UpgradeStatus: No upgrade log present (probably fresh install)