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: (on-topic) Re: bug#19479: Package manager vulnerable Date: Sun, 11 Jan 2015 02:56:22 +0000 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1420945097 24544 80.91.229.3 (11 Jan 2015 02:58:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 11 Jan 2015 02:58:17 +0000 (UTC) To: 19479@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jan 11 03:58:10 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 1YA8jC-0004eT-6j for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 Jan 2015 03:58:10 +0100 Original-Received: from localhost ([::1]:57145 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YA8jB-0003AD-Er for geb-bug-gnu-emacs@m.gmane.org; Sat, 10 Jan 2015 21:58:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35870) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YA8j8-00039H-41 for bug-gnu-emacs@gnu.org; Sat, 10 Jan 2015 21:58:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YA8j4-0003YY-Uc for bug-gnu-emacs@gnu.org; Sat, 10 Jan 2015 21:58:06 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:32943) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YA8j4-0003YU-R3 for bug-gnu-emacs@gnu.org; Sat, 10 Jan 2015 21:58:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YA8j4-0006Eu-Ga for bug-gnu-emacs@gnu.org; Sat, 10 Jan 2015 21:58:02 -0500 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Kelly Dean Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Jan 2015 02:58:02 +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.142094503923900 (code B ref 19479); Sun, 11 Jan 2015 02:58:02 +0000 Original-Received: (at 19479) by debbugs.gnu.org; 11 Jan 2015 02:57:19 +0000 Original-Received: from localhost ([127.0.0.1]:42309 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YA8iM-0006DQ-L1 for submit@debbugs.gnu.org; Sat, 10 Jan 2015 21:57:19 -0500 Original-Received: from relay4-d.mail.gandi.net ([217.70.183.196]:50342) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YA8iJ-0006DB-FL for 19479@debbugs.gnu.org; Sat, 10 Jan 2015 21:57:16 -0500 Original-Received: from mfilter15-d.gandi.net (mfilter15-d.gandi.net [217.70.178.143]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 884B017207C for <19479@debbugs.gnu.org>; Sun, 11 Jan 2015 03:57:14 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter15-d.gandi.net Original-Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter15-d.gandi.net (mfilter15-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id HZucTgHAMMs1 for <19479@debbugs.gnu.org>; Sun, 11 Jan 2015 03:57:13 +0100 (CET) X-Originating-IP: 66.220.3.179 Original-Received: from localhost (gm179.geneticmail.com [66.220.3.179]) (Authenticated sender: kelly@prtime.org) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 9BCA8172077 for <19479@debbugs.gnu.org>; Sun, 11 Jan 2015 03:57:11 +0100 (CET) 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:98213 Archived-At: Back on topic... I found a good way to add timestamps to prevent metadata replay (the othe= r vulnerability), and to further harden the package manager's security, b= ut of course I'll wait until we hear from the clerk before trying to impl= ement it. The reason I said there's a compatibility problem for timestamps is that = archive-contents is a list consisting just of a version number followed b= y a bunch of package records; the list's format isn't extensible (though = the package record format is extensible). There's no way to insert a time= stamp without changing the list's format (and thus, the version number), = but if you do that, then old clients can't understand archive-contents an= ymore. Even worse, old clients become stuck because they store the new-format (i= ncompatible) file before checking the version number, then barf on it and= refuse to accept even an old-format (compatible) file to replace it unti= l you manually delete the stored one. I see four possible solutions: 0. Have a flag day, on which all the elpas switch to the new format, and = on or before which everybody must upgrade to Emacs 25 or his package mana= ger will stop working. 1. Have the server check the User-Agent header, and send the old-format f= ile if it's =E2=8C=9CURL/Emacs=E2=8C=9D, and the new-format if it's =E2=8C= =9CURL/Emacs-25=E2=8C=9D or later. 2. Use a different URL for the new-format file. 3. Keep the old format, and put the timestamp in a different file. #0 obviously isn't an option. I advise against #1, for reasons which everybody here already knows. #2 would work, but is inelegant, since you would still have to retain the= old-format file for the sake of old clients, and it's inefficient, since= new clients would have to periodically re-download the entire file (fair= ly big, in Melpa's case) even if nothing but the timestamp changed (and c= lients have to demand fresh timestamps in order to prevent metadata repla= y attacks). #3 looks like the best solution. The timestamp file includes the timestam= p and the hash of archive-contents. Sign the timestamp file for the sake = of new clients. Old clients would ignore the timestamp file. If archive-contents is uncha= nged, then new clients would only have to periodically re-download the ti= mestamp file and signature--the minimal amount of data necessary. They'd = see that the current hash of archive-contents matches the version they al= ready have stored. IOW, to whoever made archive-contents inextensible: th= ank you! You've forced the right solution to timestamping. ;-) Combined with my previous patch, this leaves the timestamp-file's signatu= re as the only one that's necessary to secure the entire archive (package= s and metadata, including timestamp) and prevent both package and metadat= a replay attacks. IMHO, this simplicity makes it practical to insist that= all elpas provide this signature, so Emacs 25 could enforce it by defaul= t. Optionally continue signing archive-contents for the sake of 24.4 clients= , but since 25 won't need that signature, nothing before 24.4 is capable = of checking it, 24.4 doesn't enforce it by default, Melpa doesn't even pr= ovide it IIUC (GNU Elpa does), and 24.4 is vulnerable to package and meta= data replay anyway, you might as well not. The kind of people who have ch= anged package-check-signature to t will upgrade to 25 anyway.