From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kelly Dean Newsgroups: gmane.emacs.bugs Subject: bug#19479: Package manager vulnerable Date: Mon, 05 Jan 2015 01:11:40 +0000 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1420420404 2199 80.91.229.3 (5 Jan 2015 01:13:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 5 Jan 2015 01:13:24 +0000 (UTC) Cc: 19479@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jan 05 02:13:18 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Y7wEP-0000j5-2m for geb-bug-gnu-emacs@m.gmane.org; Mon, 05 Jan 2015 02:13:17 +0100 Original-Received: from localhost ([::1]:58661 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y7wEO-00036q-4r for geb-bug-gnu-emacs@m.gmane.org; Sun, 04 Jan 2015 20:13:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42524) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y7wEF-00035I-Ki for bug-gnu-emacs@gnu.org; Sun, 04 Jan 2015 20:13:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y7wEA-00018f-FA for bug-gnu-emacs@gnu.org; Sun, 04 Jan 2015 20:13:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55659) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y7wEA-00018b-BF for bug-gnu-emacs@gnu.org; Sun, 04 Jan 2015 20:13:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Y7wE9-0006Cw-UW for bug-gnu-emacs@gnu.org; Sun, 04 Jan 2015 20:13:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Kelly Dean Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 05 Jan 2015 01:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19479 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: security Original-Received: via spool by 19479-submit@debbugs.gnu.org id=B19479.142042034923820 (code B ref 19479); Mon, 05 Jan 2015 01:13:01 +0000 Original-Received: (at 19479) by debbugs.gnu.org; 5 Jan 2015 01:12:29 +0000 Original-Received: from localhost ([127.0.0.1]:36792 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y7wDc-0006C7-ES for submit@debbugs.gnu.org; Sun, 04 Jan 2015 20:12:28 -0500 Original-Received: from relay6-d.mail.gandi.net ([217.70.183.198]:60514) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y7wDa-0006Bz-Fx for 19479@debbugs.gnu.org; Sun, 04 Jan 2015 20:12:27 -0500 Original-Received: from mfilter3-d.gandi.net (mfilter3-d.gandi.net [217.70.178.133]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id B70BBFB87D; Mon, 5 Jan 2015 02:12:25 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter3-d.gandi.net Original-Received: from relay6-d.mail.gandi.net ([217.70.183.198]) by mfilter3-d.gandi.net (mfilter3-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id NGVQfDuhw36v; Mon, 5 Jan 2015 02:12:24 +0100 (CET) X-Originating-IP: 162.248.99.114 Original-Received: from localhost (114-99-248-162-static.reverse.queryfoundry.net [162.248.99.114]) (Authenticated sender: kelly@prtime.org) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 1FDD6FB86E; Mon, 5 Jan 2015 02:12:21 +0100 (CET) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:98015 Archived-At: Stefan Monnier wrote: > AFAICT, this vulnerability also applies to the way GNU packages are > distributed in ftp.gnu.org (i.e. as a tarball plus a .sig file). > > Is that right? Yes, because there are no hashes in, or signatures on, http://ftp.gnu.org/find.txt.gz or http://ftp.gnu.org/ls-lrRt.txt.gz They used to do it right; see http://ftp.gnu.org/before-2003-08-01.md5sums.asc But it looks like they stopped. Having to redo a huge monolithic metadata file whenever any data file changes is inefficient; it's more efficient for the metadata for each directory to just have the hash of each file in the directory and the hash of the metadata of each subdirectory, like Git does. But either way will prevent package replay attacks. >> Executive summary to fix the vulnerabilities: > > Another way to attack the problem is to include the file name along with > its content in "the thing that gets signed". > I.e. the signature shouldn't apply to the output of "cat " but to > the output of "echo ; cat ". > > This way an attacker can't take .tar along with > .tar.sig and send them off as .tar along with > .tar.sig. If filenames include version numbers and the version numbers are never reused, then your solution does prevent package replay attacks. Since Emacs packages already include a Version header (and the package name), you could actually do your proposed verification using that header, without changing the way signatures are currently made, which is a solution I addressed in my original emacs-devel message. But having a list of hashes of all the packages (and even better, chaining together all the versions of that list) makes changes to any package more conspicuous, which makes the attacker's job harder, as I explained. And if you do that, then the elpa key no longer needs to sign individual packages at all. Git, Fossil, and Debian's apt-get use hash lists, and Git and Fossil also chain together the lists, so there's good precedence. Both are simple to do for Emacs: in the archive-contents file, include the hash of each package and the hash of the previous version of archive-contents. But remember, none of the above prevents metadata replay attacks. If the user himself is specifying the metadata (e.g. you manually request Emacs 24.4 because you know that's the latest version), then verification to prevent metadata replay attacks isn't the computer's job. But when the user just says to update some package(s) to the latest version, without specifying the version, then it is the computer's job. For this, put a timestamp of the archive-contents file into the file itself.