*** This bug is a security vulnerability ***
You have been subscribed to a public security bug by Marc Deslauriers
(mdeslaur):
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)
** Affects: emacs24 (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug trusty
--
package.el downloads unsigned code over HTTP and executes it
https://bugs.launchpad.net/bugs/1424456
You received this bug notification because you are a member of Ubuntu Bugs,
which is subscribed to the bug report.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
