Delivery-date: Thu, 28 Mar 2024 11:50:58 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::d2b as permitted sender) client-ip=2607:f8b0:4864:20::d2b;
MIME-Version: 1.0
References: <f7fbeb4f58904fc5a24b6fc2d829036c@dtrt.org> <ZgRfvrYatcpqPNRn@petertodd.org>
 <bbc33ff01e464f8c84a593ac05c5722c@dtrt.org> <ZgSB6kmLiDG08Yrd@petertodd.org> <CABu3BAeYsMG7TuM_htTYREgDdGOKV=gwFJ+T59L=qHqbewz4vw@mail.gmail.com>
In-Reply-To: <CABu3BAeYsMG7TuM_htTYREgDdGOKV=gwFJ+T59L=qHqbewz4vw@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Thu, 28 Mar 2024 18:34:42 +0000
Message-ID: <CALZpt+EK26=E6U9OdY+c9LVQnGtb-f5zzKt5RTwBoHpr_SSxcA@mail.gmail.com>
Subject: Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
To: Steve Lee <steven.j.lee@gmail.com>
Cc: Peter Todd <pete@petertodd.org>, "David A. Harding" <dave@dtrt.org>, bitcoindev@googlegroups.com
Content-Type: multipart/alternative; boundary="0000000000008021850614bcc7c6"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

--0000000000008021850614bcc7c6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Steve,

> He literally cites a reference to an example.

About CVE-2017-12842,  the report of Sergio Demian Lerner available here
gives more information on the reporting process of the vulnerability:
https://bitslog.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-de=
sign/

I'll attract attention on the following words of Sergio himself:

"and as I said in the first paragraph, the weakness was already known by
some developers. But I still don't understand (1) why so many people knew
about it but underestimated it badly, (2) why there was no attempt to fix
it."

Sadly, from my experience reporting weaknesses or reviewing security
patches in Bitcoin Core, senior developers in this field are still aware of
more vulnerabilities than they usually have time to fix them. Additionally,
sometimes "ambiguous" patches are deliberately done where a lightweight
weakness is fixed and argued in public as such, when in reality more severe
issues are hardened under the hood.

In the present case making non-standard 64 bytes transactions without
witness in Bitcoin Core 16.0 added a belt-and-suspender in face of
block-malleability validation issues that could split the network _and_ it
leveled up the bar for double-spending SPV clients. That latest
exploitation scenario was the one which was early disclosed by Peter in
June 2018.

Coming back to the present "free-relay" bandwidth wasting class of attack
disclosure, I effectively myself think a 4-days delay was a bit short for a
full disclosure.

Comparing to CVE-2021-31876 (core's lack of inheritance signaling), full
disclosure report is available here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018893.htm=
l

The initial report was made 2021-03-19. We didn't go the route of landing a
covert patch as it was appreciated that potential DoS risks outweighs the
safety of non-anchors exposed LN channels. Weakness report was made
available the 2021-05-06 after noticing maintainers of most-likely exposed
Bitcoin softwares, so a delay of 50-days. As a reminder, in the full
disclosure report I myself champion some changes in the BOLT protocol such
as dynamic upgrades that would make handling this kind of security issues
easier [0].

I believe in the present "free-relay" bandwidth wasting, letting a minimal
2-weeks delay would have been more reasonable. Security list members might
be in flight travels or at conferences, or under other operational
constraints and domain experts in the area of transaction-relay might not
be available to give full-fledged answers. Even if you have private
contacts of someone, don't rush them to get an answer when it can be
midnight in their time zones and they're recovering from jet lags.

On the other hand, if you don't receive a satisfying answer as a security
finding reporter after 2 weeks, or an acknowledgement of email reporting
reception after ~72 hours from vendors, I still think you're free to move
ahead with a full disclosure. Sadly, I had "bad faith" vendor cases in my
career as a security researcher in considerations of ethical infosec rules.

Best,
Antoine

[0] By the way the pinning vector exposed in CVE-2021-31876 still affects
LDK channels as the commit beef584c `negotiate_anchors_zero_fee_htlc_tx` is
false by default. And this is not fixed by v3 without avoiding all
nversion=3D2 by an on-chain confirmation to be replayed (L792,
src/validation.cpp - commit d1e9a02). I"ll be polite and not ask what LDK
maintainers are doing with their time.


Le mer. 27 mars 2024 =C3=A0 22:14, Steve Lee <steven.j.lee@gmail.com> a =C3=
=A9crit :

>
>
> On Wed, Mar 27, 2024 at 2:56=E2=80=AFPM Peter Todd <pete@petertodd.org> w=
rote:
>
>>
>> I'm not the only person who thinks this looks like harassment. The fact
>> is you
>> started this conversation with: "I'm especially concerned given your pas=
t
>> history of publicly revealing vulnerabilities before they could be quiet=
ly
>> patched and the conflict of interest of you using this disclosure to
>> advocate
>> for a policy change you are championing."
>>
>> You haven't substantiated any of this.
>
>
> He literally cites a reference to an example.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/bitcoindev/EJYoeNTPVhg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/bitcoindev/CABu3BAeYsMG7TuM_htTYREgDdGO=
KV%3DgwFJ%2BT59L%3DqHqbewz4vw%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CABu3BAeYsMG7TuM_htTYREgDdG=
OKV%3DgwFJ%2BT59L%3DqHqbewz4vw%40mail.gmail.com?utm_medium=3Demail&utm_sour=
ce=3Dfooter>
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/CALZpt%2BEK26%3DE6U9OdY%2Bc9LVQnGtb-f5zzKt5RTwBoHpr_SSxcA%40mail=
.gmail.com.

--0000000000008021850614bcc7c6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Steve,<div><br></div><div>&gt; He literally cites a ref=
erence to an example.</div><span class=3D"gmail-im" style=3D"color:rgb(80,0=
,80)"><p></p></span>About CVE-2017-12842, =C2=A0the report of Sergio Demian=
 Lerner available here gives more information on the reporting process of t=
he vulnerability:<div><a href=3D"https://bitslog.com/2018/06/09/leaf-node-w=
eakness-in-bitcoin-merkle-tree-design/">https://bitslog.com/2018/06/09/leaf=
-node-weakness-in-bitcoin-merkle-tree-design/</a><br></div><div><br></div><=
div>I&#39;ll attract attention on the following words of Sergio himself:</d=
iv><div><br></div><div>&quot;and as I said in the first=C2=A0paragraph, the=
 weakness was already known by some developers. But I still don&#39;t under=
stand (1) why so many people knew about it but underestimated it badly, (2)=
 why there was no attempt to fix it.&quot;</div><div><br></div><div>Sadly, =
from my experience reporting weaknesses or reviewing security patches in Bi=
tcoin Core, senior developers in this field are still aware of more vulnera=
bilities than they usually have time to fix them. Additionally, sometimes &=
quot;ambiguous&quot; patches are deliberately done where a lightweight weak=
ness is fixed and argued in public as such, when in reality more severe iss=
ues are hardened under the hood.</div><div><br></div><div>In the present ca=
se making non-standard 64 bytes transactions without witness in Bitcoin Cor=
e 16.0 added a belt-and-suspender in face of block-malleability validation =
issues that could split the network _and_ it leveled up the bar for double-=
spending SPV clients. That latest exploitation scenario was the one which w=
as early disclosed by Peter in June 2018.</div><div><br></div><div>Coming b=
ack to the present &quot;free-relay&quot; bandwidth wasting class of attack=
 disclosure, I effectively myself think a 4-days delay was a bit short for =
a full disclosure.</div><div><br></div><div>Comparing to CVE-2021-31876 (co=
re&#39;s lack of inheritance signaling), full disclosure report is availabl=
e here:</div><div><a href=3D"https://lists.linuxfoundation.org/pipermail/bi=
tcoin-dev/2021-May/018893.html">https://lists.linuxfoundation.org/pipermail=
/bitcoin-dev/2021-May/018893.html</a><br></div><div><br></div><div>The init=
ial report was made 2021-03-19. We didn&#39;t go the route of landing a cov=
ert patch as it was appreciated that potential DoS risks outweighs the safe=
ty of non-anchors exposed LN channels. Weakness report was made available t=
he 2021-05-06 after noticing maintainers of most-likely exposed Bitcoin sof=
twares, so a delay of 50-days. As a reminder, in the full disclosure report=
 I myself champion some changes in the BOLT protocol such as dynamic upgrad=
es that would make handling this kind of security issues easier [0].</div><=
div><br></div><div>I believe in the present &quot;free-relay&quot; bandwidt=
h wasting, letting a minimal 2-weeks delay would have been more reasonable.=
 Security list members might be in flight travels or at conferences, or und=
er other operational constraints and domain experts in the area of transact=
ion-relay might not be available to give full-fledged answers. Even if you =
have private contacts of someone, don&#39;t rush them to get an answer when=
 it can be midnight in their time zones and they&#39;re recovering from jet=
 lags.</div><div><br></div><div>On the other hand, if you don&#39;t receive=
 a satisfying answer as a security finding reporter after 2 weeks, or an ac=
knowledgement of email reporting reception after ~72 hours from vendors, I =
still think you&#39;re free to move ahead with a full disclosure. Sadly, I =
had &quot;bad faith&quot; vendor cases in my career as a security researche=
r in considerations of ethical=C2=A0infosec rules.</div><div><br></div><div=
>Best,</div><div>Antoine</div><div><br></div><div>[0] By the way the pinnin=
g vector exposed in CVE-2021-31876 still affects LDK channels as the commit=
 beef584c=C2=A0`negotiate_anchors_zero_fee_htlc_tx` is false by default. An=
d this is not fixed by v3 without avoiding all nversion=3D2 by an on-chain =
confirmation to be replayed (L792, src/validation.cpp - commit d1e9a02). I&=
quot;ll be polite and not ask what LDK maintainers are doing with their tim=
e.</div><div><div><br></div></div></div><br><div class=3D"gmail_quote"><div=
 dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mer. 27 mars 2024 =C3=A0=C2=A022:=
14, Steve Lee &lt;<a href=3D"mailto:steven.j.lee@gmail.com">steven.j.lee@gm=
ail.com</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-sty=
le:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote"><div dir=3D"l=
tr" class=3D"gmail_attr">On Wed, Mar 27, 2024 at 2:56=E2=80=AFPM Peter Todd=
 &lt;<a href=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@petertodd=
.org</a>&gt; wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left=
-color:rgb(204,204,204);padding-left:1ex">
<br>
I&#39;m not the only person who thinks this looks like harassment. The fact=
 is you<br>
started this conversation with: &quot;I&#39;m especially concerned given yo=
ur past<br>
history of publicly revealing vulnerabilities before they could be quietly<=
br>
patched and the conflict of interest of you using this disclosure to advoca=
te<br>
for a policy change you are championing.&quot;<br>
<br>
You haven&#39;t substantiated any of this. </blockquote><div><br></div><div=
>He literally cites a reference to an example.</div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
d/topic/bitcoindev/EJYoeNTPVhg/unsubscribe" target=3D"_blank">https://group=
s.google.com/d/topic/bitcoindev/EJYoeNTPVhg/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" target=3D"_blank">bitco=
indev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/CABu3BAeYsMG7TuM_htTYREgDdGOKV%3DgwFJ%2BT59L%3DqHqbew=
z4vw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D=
"_blank">https://groups.google.com/d/msgid/bitcoindev/CABu3BAeYsMG7TuM_htTY=
REgDdGOKV%3DgwFJ%2BT59L%3DqHqbewz4vw%40mail.gmail.com</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/CALZpt%2BEK26%3DE6U9OdY%2Bc9LVQnGtb-f5zzKt5RTwBoHpr_S=
SxcA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://group=
s.google.com/d/msgid/bitcoindev/CALZpt%2BEK26%3DE6U9OdY%2Bc9LVQnGtb-f5zzKt5=
RTwBoHpr_SSxcA%40mail.gmail.com</a>.<br />

--0000000000008021850614bcc7c6--