Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 90448BDF for ; Mon, 11 Sep 2017 18:29:48 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com [209.85.213.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3E22D455 for ; Mon, 11 Sep 2017 18:29:48 +0000 (UTC) Received: by mail-vk0-f44.google.com with SMTP id w23so1857017vkw.2 for ; Mon, 11 Sep 2017 11:29:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=wOGn4i/yuZhIbZ4kEaeUTiu4GK2bsA9Y4Zkak+/kPmU=; b=bSr9qoLorcrRCjw2pwiHUk46nUA7f7a13Kra5m1BEZ72G0aT7n+jscTP3bxqmFbRsd 3SmPSGuO/7h9p5ImunUNNq47sOsz2TOAZXSfe9xNi8uyoS9zINHX0kwhemL3UzFByT6F cKxf9bp1vRSb2WGkZhMVGZDh+gkm4gPMK1F9MYwoswiMlL5WCP2YZk530BPQPohdqyZL qF9kdldKEwQG6pN5HTFiffIrDgD3X8AMKZdJSMw8ymzNhlgQX9Iql+KQ92F0jZJ+nTyI Drsul3ZocJQtzu/lQ6mzIQ0T0+rFWzRqZg8k08n6bJbtXbIZ830C6aSvefNTIaKIg5EN qrFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=wOGn4i/yuZhIbZ4kEaeUTiu4GK2bsA9Y4Zkak+/kPmU=; b=mSzy3zWCYP2/Sjc4+2X5ig/dAKhQva7zW9G6FEikM9Vh+IHwlyeSw01IzED+TWE+GF AqMgQCiZoQIRNR88fSR3Ao8LqMjcMQAkmcJEiNu+u1MWZgz7RmElm9G7r8cTX/B+GGeo En6w/HSSBxWDQCcJEqh2qJlMlmmV9eH6QEOCmpY9THC+tqtZdmViQ1986vdC4egO1A/J YLADsvCvFIyX5Hy++YKJSfrQY7tGU3aAcZmmlgaA4FGUkcSritEDbTkG1QfsJ+TE3OM9 6W47MJGx9jMYCJurrs/rmYnspQOPIj1cJgj3zenRAoT/otpl1irGu02wwTVLPPsH72tK Gm6A== X-Gm-Message-State: AHPjjUhRnZKZLIHdF6OToqgMtRDCqQvJF7lhtLFIXgoBT3xDYl6BB9H8 2gYvF6rSgvNwEON7JCary7V9czOotw== X-Google-Smtp-Source: AOwi7QBbGADuwOvkbjL5pWdXIzYx7SruFiieNqzFvGhKhcHciVso9h6Y+QLAUicLNnHKwv6B12sJ3dqaYxRqwJFn4zA= X-Received: by 10.31.160.204 with SMTP id j195mr8852805vke.172.1505154587316; Mon, 11 Sep 2017 11:29:47 -0700 (PDT) MIME-Version: 1.0 Sender: gmaxwell@gmail.com Received: by 10.103.146.78 with HTTP; Mon, 11 Sep 2017 11:29:46 -0700 (PDT) In-Reply-To: References: <3e4541f3-f65c-5199-5e85-9a65ea5142e7@bitcartel.com> <20170911021506.GA19080@erisian.com.au> From: Gregory Maxwell Date: Mon, 11 Sep 2017 18:29:46 +0000 X-Google-Sender-Auth: _e3tpdceiHHtMroR419E0jCTGF0 Message-ID: To: Daniel Stadulis , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Responsible disclosure of bugs X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 18:29:48 -0000 On Mon, Sep 11, 2017 at 5:43 PM, Daniel Stadulis via bitcoin-dev wrote: > I think it's relevant to treat different bug severity levels with different > response plans. > > E.g. > Compromising UTXO custody (In CVE-2010-5141, OP_RETURN vulnerability) > Compromising UTXO state (In CVE-2013-3220, blockchain split due to Berkeley > DB -> LevelDB upgrade, CVE-2010-5139 Overflow bug, unscheduled inflation of > coins) > Compromising Node performance (Various node-specific DoS attacks) > > Should have different disclosure policies, IMO This assumes the states are discernible. They often aren't cleanly. You obviously know how bad it is in the best case, but the worst could be much worse. I've multiple time seen a hard to exploit issue turn out to be trivial when you find the right trick, or a minor dos issue turn our to far more serious. Simple performance bugs, expertly deployed, can potentially be used to carve up the network--- miner A and exchange B go in one partition, everyone else in another.. and doublespend. And so on. So while I absolutely do agree that different things should and can be handled differently, it is not always so clear cut. It's prudent to treat things as more severe than you know them to be. In fact, someone pointed out to me a major amplifier of the utxo-memory attack thing today that Bitcoin Core narrowly dodges which would have made it very easy to exploit against some users, and which it seems no one previously considered. I also think it's somewhat incorrect to call this thread anything about disclosure, this thread is not about disclosure. Disclosure is when you tell the vendor. This thread is about publication and that has very different implications. Publication is when you're sure you've told the prospective attackers.