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 22:02:32 -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="32800"; 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 04:03:23 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 1ki7Z5-0008Qp-Ml for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 26 Nov 2020 04:03:23 +0100 Original-Received: from localhost ([::1]:40372 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ki7Z4-000325-Jd for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 25 Nov 2020 22:03:22 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45988) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ki7Yl-00031v-0s for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2020 22:03:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54339) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ki7Yk-0004no-99 for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2020 22:03:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ki7Yk-00056x-5F for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2020 22:03: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 03:03: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.160635976019618 (code B ref 19479); Thu, 26 Nov 2020 03:03:02 +0000 Original-Received: (at 19479) by debbugs.gnu.org; 26 Nov 2020 03:02:40 +0000 Original-Received: from localhost ([127.0.0.1]:37652 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ki7YN-00056M-Kr for submit@debbugs.gnu.org; Wed, 25 Nov 2020 22:02:39 -0500 Original-Received: from mail-ej1-f49.google.com ([209.85.218.49]:37221) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ki7YM-00056A-JL for 19479@debbugs.gnu.org; Wed, 25 Nov 2020 22:02:39 -0500 Original-Received: by mail-ej1-f49.google.com with SMTP id z5so757904ejp.4 for <19479@debbugs.gnu.org>; Wed, 25 Nov 2020 19:02:38 -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=rJh2qDiUkHZrj2Z7OGSGz6GQf92K2c9jdetbwxjtRso=; b=hQhwaEMCx1H80uOmjJfKXXsoDm+nKZBSe4Q1Mz/se8OxMB070nAmxhlWQgxtErEcXv 89On9B0uUr2gwWV/jSLWSL2k0zmdZmkO/eSpcRaoNr1c1WjvL1973j+GCTO62RAdBJN1 uMHcizsR+SgEBq95o0qdCVNuaLZkJRJZSVSE85Z5Cd3g2xvBpz27p/oA+iKjwSXrHVkJ gIjcJpyI0mnjz5MiT8BPXfHHX0givSyvk5Fy+Qz9M85iLGKTZSjEbb8UiBm8as2O9uT0 Z1aWUs/q92HooMW17twCwmjBzWjuoPhsTay4Koo91aKcExV1ylbPGfUz8jrxIUEOrQa+ YjXw== X-Gm-Message-State: AOAM532l8So9MHEKtJu6xPEBVshGLYlW6dc4eQV9E7SoffQLSPr9mclF fIkl3+KA2P/Rum8TaIQv6PjDyZNwV/Bc90nSU3E= X-Google-Smtp-Source: ABdhPJzUBTdK35fhu2A6rRaQr5EezfL3hOxqjYM8iHdmvfNgp/4rVDNL8KJQVuB+Mczc8c2T0Gji9/BcY6EmKl/tIFU= X-Received: by 2002:a17:906:1918:: with SMTP id a24mr849614eje.432.1606359752872; Wed, 25 Nov 2020 19:02:32 -0800 (PST) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Wed, 25 Nov 2020 22:02:32 -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:194256 Archived-At: Stefan Monnier writes: >> 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. > > I'm not sure what you mean by it being easier: since the tarballs are > cryptographically signed, just like `archive-contents`, if > `archive-contents` points to `foo-42.1.tar` and that tarball has > a correct signature and its content says that it is indeed the package > `foo-42.1`, then I'm not sure which easy attack would be applicable. I guess it's in the nature of attacks that we generally don't know or think about them in advance. This is precisely why, when it comes to security, it IMO a good idea to use battle-tested and generally accepted solutions. > AFAICT you'd have to find some old signed tarball which we accidentally > built with an incorrect content? But presumably if we ever mess up > a tarball like that (which is indeed possible), we'd then want to be > careful not to "reuse" that version number, no? I'm not sure we can assume that we would always detect when we mess up. But yes, this sounds like one possible attack vector. > I think it's comparable: the main failings wold require some error on > our side in how we build and sign packages, and in most such cases > I think we'd end up with holes with either scheme. Agreed, we could make mistakes in implementing either scheme. FWIW, I think that with the version number idea, there are more places where we could make important mistakes, since more code would be involved. There are also more assumptions that we need to ensure hold true under all circumstances. (But see below.) >> But we could of course also check that the version number is correct. >> That sounds like a useful sanity check to do. > > Exactly. How about adding this check in addition to the checksum check? Having two separate checks together should surely bring more confidence than either of them would separately. That sounds like good "defense in depth" thinking to me. > I think we'd want to keep the signatures anyway, e.g. they can still be > checked manually for old tarballs which aren't listed in > `archive-contents` any more. And more generally they allow > authenticating the origin of a package without having to look it up in > `archive-contents`. Valid points. Let's keep them indefinitely.