From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.bugs Subject: bug#19479: Package manager vulnerable to replay attacks Date: Wed, 25 Nov 2020 21:06:38 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="752"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 19479@debbugs.gnu.org, Noam Postavsky To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Nov 26 03:07:15 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ki6gl-00005m-On for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 26 Nov 2020 03:07:15 +0100 Original-Received: from localhost ([::1]:52192 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ki6gk-0001Ml-Qz for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 25 Nov 2020 21:07:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36054) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ki6gY-0001Jr-KH for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2020 21:07:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54269) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ki6gY-0002bK-Ax for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2020 21:07:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ki6gY-0003ln-50 for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2020 21:07:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Nov 2020 02:07: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.160635640714470 (code B ref 19479); Thu, 26 Nov 2020 02:07:02 +0000 Original-Received: (at 19479) by debbugs.gnu.org; 26 Nov 2020 02:06:47 +0000 Original-Received: from localhost ([127.0.0.1]:37582 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ki6gI-0003lJ-SI for submit@debbugs.gnu.org; Wed, 25 Nov 2020 21:06:47 -0500 Original-Received: from mail-ed1-f54.google.com ([209.85.208.54]:44033) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ki6gH-0003l6-Cb for 19479@debbugs.gnu.org; Wed, 25 Nov 2020 21:06:45 -0500 Original-Received: by mail-ed1-f54.google.com with SMTP id l5so517554edq.11 for <19479@debbugs.gnu.org>; Wed, 25 Nov 2020 18:06:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=mva3Xd4cMis/vSPZF6tmCajfM0W2zhLkFG5Gbr78+V4=; b=mQ5NJ2bQSxfanh3JiyShP+aQw96rF5qv+wprCe72VPWjdZUoh2dTTYqEnmhD6ecIyd +Q/6yz+irYuC3dbKDi8+mpsImtWdiUrHV7xJ5WDoSv/CFOYs8OhOLlLX5mPmLoed94uW yjumG92U7komxQzJVVvfZv6ES+1eMqpa1LYShWs2Mvd076QEDr7xAfAzng9OpKHNfKq/ C15RXYGPLuqsuGqVHA0W0bHR9Wvz/S3+ZpGvCPBNLctpmyrJkLwe1k9VVdqmv1o7Bi39 QL8E/PpZL5o04DiREwX4QKHxDtIRu/t2sRwgbZAMt2oE75nUU4XzoVMaanCFhupbsdZO Fasw== X-Gm-Message-State: AOAM530fBHh8vKTrl0IMW4zF6dayfNjCnatNJWdJUY369XqssWANXjsd y1dI/C8M06xyy6NwJavFys79Ah3nhseKki6oNtQ= X-Google-Smtp-Source: ABdhPJwyIkGcJSBNl6MO4W0uPhfOAkxpKY9MNLTyBuBIa7bt8hrez1tpEV+LlxaeSS/ABWI9Ms8Jbtlg01CJKCfB8FQ= X-Received: by 2002:a05:6402:b10:: with SMTP id bm16mr496599edb.214.1606356399699; Wed, 25 Nov 2020 18:06:39 -0800 (PST) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Wed, 25 Nov 2020 21:06:38 -0500 In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:194253 Archived-At: Stefan Monnier writes: > Do we need this hash-checksum, really? AFAIK, a cryptographic hash is the generally accepted solution for securely verifying the contents of a file. That is, when you worry about that file having been tampered with by a hostile actor. > AFAICT, I think if we want to avoid replay attacks we need indeed > a monotone "counter" (e.g. a timestamp) on the `archive-contents` and > then a way to verify that the tarballs are what they claim to be. We also need to sign `archive-contents', of course. But otherwise correct: we need to know that the metadata is not out-of-date, and we need to have a (secure) mapping from the package metadata to individual packages. > We can already verify that they are what they claim to be since the > tarball includes the version number inside the `-pkg.el` file. > > So, I think all we need is to verify the contents of `-pkg.el` > after unpacking a tarball, to make sure it is indeed the package and > version its name claimed to be. This check would be welcome in any case > to detect packaging errors. I think the question here is: how do we securely map from the (signed) package metadata to an individual package? While not perfect, with a secure hash function, collisions are hard enough to find that we for our purposes (like the rest of the world) can happily not worry about it. In comparison, it is immeasurably easier to fake a version number than having to defeat a hash function. I think this is a significant drawback of what you propose. We would need to add in a number of assumptions (e.g. packages are individually signed, we never accidentally sign an old package with a newer version number, etc.), to gain more confidence in a simple version number check. But even then the security it provides will not be as strong, and much more brittle; there are just more moving parts where things could go wrong. And I'm not sure what we would gain. Importantly, I don't think it would simplify our implementation in Emacs (or GNU/NonGNU ELPA) significantly. But we could of course also check that the version number is correct. That sounds like a useful sanity check to do. Thanks for taking a look at this! PS. Note that if we add a checksum, there will no longer be any need to sign individual packages for future versions of Emacs. We would then only need to sign the metadata.