desktop-packages team mailing list archive

[Marc Deslauriers <marc.deslauriers@xxxxxxxxxxxxx>]

** Information type changed from Private Security to Public Security

** Changed in: emacs24 (Ubuntu)
       Status: New => Confirmed

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to emacs24 in Ubuntu.
https://bugs.launchpad.net/bugs/1424456

Title:
  package.el downloads unsigned code over HTTP and executes it

Status in emacs24 package in Ubuntu:
  Confirmed

Bug description:
  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)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1424456/+subscriptions