Delivery-date: Sun, 07 Apr 2024 01:28:33 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of ali@notatether.com designates 185.70.40.22 as permitted sender) client-ip=185.70.40.22;
Date: Sun, 07 Apr 2024 08:03:52 +0000
To: "bitcoindev@googlegroups.com" <bitcoindev@googlegroups.com>
From: Ali Sherief <ali@notatether.com>
Subject: Re: [bitcoindev] Security implications of using pseudorandom JSON-RPC IDs
Message-ID: <5U7FixH_a7lxjcGGxLi5i-XRPXSVQfMyFHyEfwI532OTI1NoGUkD1s8Is3lEj07bL_1znuiEUwRfd7RNTdsA0kRLcRP1BNBZznHDD3YY0Sw=@notatether.com>
In-Reply-To: <HKLeYC_TSyA-x9bqKW2ono6zSUV3XpVsu2S1uPMU3NBnXTGHxZ1bLx0K9YztYRK-3kKXsWtz0TCrKsNg5BkvNnNKzX9zwRtl5slNRVsLSzA=@notatether.com>
References: <a358aaac-62d5-4d30-a599-40c94da66c4fn@googlegroups.com> <xXMlG6tjc8Zq-mJ5J6mM8xCqSbzLeJMP6pHmaEsrmkmqXlTLhroNtaPtY16nHq0u5APSMY4F518X22fWSjRBQ_MWpqkfN-jnceZxHsZU14k=@proton.me> <HKLeYC_TSyA-x9bqKW2ono6zSUV3XpVsu2S1uPMU3NBnXTGHxZ1bLx0K9YztYRK-3kKXsWtz0TCrKsNg5BkvNnNKzX9zwRtl5slNRVsLSzA=@notatether.com>
Feedback-ID: 34210769:user:proton
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="b1_dz10CEF07ZpdMXeDwRZ6FMRamKxfAOMlSbx367YKGE"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

This is a multi-part message in MIME format.

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

I think the conversation did not get sent to the mailing list somehow. Stil=
l trying to get the hang of Google Groups I guess. Anyway I'm going to forw=
ard it here just to be sure.

---Ali
------- Forwarded Message -------
From: Ali Sherief <ali@notatether.com>
Date: On Sunday, April 7th, 2024 at 7:47 AM
Subject: Re: [bitcoindev] Security implications of using pseudorandom JSON-=
RPC IDs
To: hashnoncemessage <hashnoncemessage@proton.me>

> Using the RPC method 'getrpcinfo', I can't seem to produce a parallel RPC=
 evaluation, even though I am using 4 RPC threads.
>
> If anyone wants to reproduce, you can simulate asynchronous calls in Bash=
 or another shell:
>
> bitcoin-cli getblockchaininfo &
> bitcoin-cli getrpcinfo
>
> The output of the second command on my machine is:
>
> {
> "active_commands": [
> {
> "method": "getrpcinfo",
> "duration": 58
> }
> ],
> "logpath": "/home/zenulabidin/.bitcoin/debug.log"}
>
> I see that there is a global work queue shared by all the threads from wh=
ich they get the RPC request from: (https://github.com/bitcoin/bitcoin/blob=
/0f0e36de5f53f82d31416dc05a24d2885781ce57/src/httpserver.cpp#L70-L125)
>
> So as I understand it, the system doesn't actually make use of the JSON-R=
PC metadata such as id, but it's just distributing the work in the queue to=
 different threads. So it is not possible to use the id to corrupt the work=
 queue.
>
> However, what I did notice is that the internal evhttp_request variables =
can (theoretically) be edited to resolve to a different pointer in order to=
 achieve the same effect, of receiving a different JSON reply. This would r=
equire some form of memory corruption bug to be found in Bitcoin Core that =
affects some global data structure that comes close enough before g_work_qu=
eue or the queue itself, so for linux-gcc on x86 platforms at least, any of=
 these variables: (https://github.com/bitcoin/bitcoin/blob/0f0e36de5f53f82d=
31416dc05a24d2885781ce57/src/httpserver.cpp#L141-L147)
>
> But it would be more likely to cause a node crash than the intended resul=
t, I think.
>
> Obviously I'm not a security researcher but I do have a good grasp of C++=
, so just doing my due diligence to check what kind of attack vectors exist=
 in my program's dependencies.
>
> ---
> Ali
>
> On Sunday, April 7th, 2024 at 6:33 AM, hashnoncemessage <hashnoncemessage=
@proton.me> wrote:
>
>> As I understand it, the json rpc server responds directly to the (http) =
request initiated by the client.
>>
>> Request IDs are used for correlation of different requests from the same=
 client.
>>
>> Core will not send your client=E2=80=99s response to a different client/=
connection.
>>
>> On Sun, Apr 7, 2024 at 07:57, Ali Sherief <[ali@notatether.com](mailto:O=
n Sun, Apr 7, 2024 at 07:57, Ali Sherief <<a href=3D)> wrote:
>>
>>> I am trying to figure out how the Bitcoin Core RPC server stores the Un=
iValue JSON-RPC requests.
>>>
>>> The reason being is because I have an application that uses pseudorando=
m IDs for the JSON-RPC calls, and I'm trying to make sure that Core isn't g=
oing to send me someone else's JSON-RPC response if somebody else happens t=
o be making a request with that ID at the same instant, which could be a po=
tential security issue.
>>>
>>> So far I don't have any leads on the Github codebase yet, but I'm still=
 looking.
>>>
>>> Anyway I would appreciate if someone would clarify this topic for me.
>>>
>>> ---
>>> Ali
>>>
>>> --
>>> You received this message because you are subscribed to the Google Grou=
ps "Bitcoin Development Mailing List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send =
an email to bitcoindev+unsubscribe@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms=
gid/bitcoindev/a358aaac-62d5-4d30-a599-40c94da66c4fn%40googlegroups.com.

--=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/5U7FixH_a7lxjcGGxLi5i-XRPXSVQfMyFHyEfwI532OTI1NoGUkD1s8Is3lEj07b=
L_1znuiEUwRfd7RNTdsA0kRLcRP1BNBZznHDD3YY0Sw%3D%40notatether.com.

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

<div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><br></div>
<div class=3D"protonmail_signature_block protonmail_signature_block-empty" =
style=3D"font-family: Arial, sans-serif; font-size: 14px;">
    <div class=3D"protonmail_signature_block-user protonmail_signature_bloc=
k-empty">
       =20
            </div>
   =20
            <div class=3D"protonmail_signature_block-proton protonmail_sign=
ature_block-empty">
       =20
            </div>
</div>
<div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><span>I thi=
nk the conversation did not get sent to the mailing list somehow. Still try=
ing to get the hang of Google Groups I guess. Anyway I'm going to forward i=
t here just to be sure.</span><div><br></div><div><span>---</span></div><sp=
an>Ali</span><br></div><div class=3D"protonmail_quote">
        ------- Forwarded Message -------<br>
        From: Ali Sherief &lt;ali@notatether.com&gt;<br>
        Date: On Sunday, April 7th, 2024 at 7:47 AM<br>
        Subject: Re: [bitcoindev] Security implications of using pseudorand=
om JSON-RPC IDs<br>
        To: hashnoncemessage &lt;hashnoncemessage@proton.me&gt;<br>
        <br>
        <blockquote class=3D"protonmail_quote" type=3D"cite">
            <div style=3D"font-family: Arial, sans-serif; font-size: 14px; =
color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">Using the RPC m=
ethod 'getrpcinfo', I can't seem to produce a parallel RPC evaluation, even=
 though I am using 4 RPC threads.</div><div style=3D"font-family: Arial, sa=
ns-serif; font-size: 14px; color: rgb(0, 0, 0); background-color: rgb(255, =
255, 255);"><br></div><div style=3D"font-family: Arial, sans-serif; font-si=
ze: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">If an=
yone wants to reproduce, you can simulate asynchronous calls in Bash or ano=
ther shell:</div><div style=3D"font-family: Arial, sans-serif; font-size: 1=
4px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br></div>=
<div style=3D"font-family: Arial, sans-serif; font-size: 14px; color: rgb(0=
, 0, 0); background-color: rgb(255, 255, 255);">bitcoin-cli getblockchainin=
fo &amp;</div><div style=3D"font-family: Arial, sans-serif; font-size: 14px=
; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">bitcoin-cli g=
etrpcinfo</div><div style=3D"font-family: Arial, sans-serif; font-size: 14p=
x; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br></div><d=
iv style=3D"font-family: Arial, sans-serif; font-size: 14px; color: rgb(0, =
0, 0); background-color: rgb(255, 255, 255);">The output of the second comm=
and on my machine is:</div><div style=3D"font-family: Arial, sans-serif; fo=
nt-size: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">=
<br></div><div style=3D"font-family: Arial, sans-serif; font-size: 14px; co=
lor: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><span>{</span><di=
v><span>&nbsp; "active_commands": [</span></div><div><span>&nbsp; &nbsp; {<=
/span></div><div><span>&nbsp; &nbsp; &nbsp; "method": "getrpcinfo",</span><=
/div><div><span>&nbsp; &nbsp; &nbsp; "duration": 58</span></div><div><span>=
&nbsp; &nbsp; }</span></div><div><span>&nbsp; ],</span></div><div><span>&nb=
sp; "logpath": "/home/zenulabidin/.bitcoin/debug.log"</span></div><span>}</=
span></div><div style=3D"font-family: Arial, sans-serif; font-size: 14px; c=
olor: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br>I see that t=
here is a global work queue shared by all the threads from which they get t=
he RPC request from: (<span><a href=3D"https://github.com/bitcoin/bitcoin/b=
lob/0f0e36de5f53f82d31416dc05a24d2885781ce57/src/httpserver.cpp#L70-L125" r=
el=3D"noreferrer nofollow noopener" target=3D"_blank">https://github.com/bi=
tcoin/bitcoin/blob/0f0e36de5f53f82d31416dc05a24d2885781ce57/src/httpserver.=
cpp#L70-L125</a>)&nbsp;</span></div><div style=3D"font-family: Arial, sans-=
serif; font-size: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 255=
, 255);"><span><br></span></div><div style=3D"font-family: Arial, sans-seri=
f; font-size: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 25=
5);"><span>So as I understand it, the system doesn't actually make use of t=
he JSON-RPC metadata such as id, but it's just distributing the work in the=
 queue to different threads. So it is not possible to use the id to corrupt=
 the work queue.</span></div><div style=3D"font-family: Arial, sans-serif; =
font-size: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);=
"><span><br></span></div><div style=3D"font-family: Arial, sans-serif; font=
-size: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><s=
pan>However, what I did notice is that the internal evhttp_request variable=
s can (theoretically) be edited to resolve to a different pointer in order =
to achieve the same effect, of receiving a different JSON reply. This would=
 require some form of memory corruption bug to be found in Bitcoin Core tha=
t affects some global data structure that comes close enough before g_work_=
queue or the queue itself, so for linux-gcc on x86 platforms at least, any =
of these variables: (<span><a href=3D"https://github.com/bitcoin/bitcoin/bl=
ob/0f0e36de5f53f82d31416dc05a24d2885781ce57/src/httpserver.cpp#L141-L147" r=
el=3D"noreferrer nofollow noopener" target=3D"_blank">https://github.com/bi=
tcoin/bitcoin/blob/0f0e36de5f53f82d31416dc05a24d2885781ce57/src/httpserver.=
cpp#L141-L147</a>)</span></span></div><div style=3D"font-family: Arial, san=
s-serif; font-size: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 2=
55, 255);"><span><span><br></span></span></div><div style=3D"font-family: A=
rial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); background-color: r=
gb(255, 255, 255);"><span><span>But it would be more likely to cause a node=
 crash than the intended result, I think.</span></span></div><div style=3D"=
font-family: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); backg=
round-color: rgb(255, 255, 255);"><span><span><br></span></span></div><div =
style=3D"background-color: rgb(255, 255, 255);"><font face=3D"Arial, sans-s=
erif">Obviously I'm not a security researcher but I do have a good grasp of=
 C++, so just doing my due diligence&nbsp;to check what kind of attack vect=
ors exist in my program's dependencies.</font></div><div style=3D"backgroun=
d-color: rgb(255, 255, 255);"><font face=3D"Arial, sans-serif"><br></font><=
/div><div style=3D"background-color: rgb(255, 255, 255);"><font face=3D"Ari=
al, sans-serif">---</font></div><div style=3D"background-color: rgb(255, 25=
5, 255);"><font face=3D"Arial, sans-serif">Ali</font></div><div style=3D"fo=
nt-family: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); backgro=
und-color: rgb(255, 255, 255);"><br></div><div class=3D"protonmail_quote">
        On Sunday, April 7th, 2024 at 6:33 AM, hashnoncemessage &lt;hashnon=
cemessage@proton.me&gt; wrote:<br>
        <blockquote class=3D"protonmail_quote" type=3D"cite">
               <div dir=3D"auto">As I understand it, the json rpc server re=
sponds directly to the (http) request initiated by the client.&nbsp;</div><=
div dir=3D"auto"><br></div><div dir=3D"auto">Request IDs are used for corre=
lation of different requests from the same client.&nbsp;</div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">Core will not send your client=E2=80=99s r=
esponse to a different client/connection.&nbsp;</div><div dir=3D"auto"><br>=
</div>On Sun, Apr 7, 2024 at 07:57, Ali Sherief &lt;<a href=3D"mailto:On Su=
n, Apr 7, 2024 at 07:57, Ali Sherief <<a href=3D" class=3D"" rel=3D"norefer=
rer nofollow noopener" target=3D"_blank">ali@notatether.com</a>&gt; wrote:<=
blockquote class=3D"protonmail_quote" type=3D"cite">  I am trying to figure=
 out how the Bitcoin Core RPC server stores the UniValue JSON-RPC requests.=
<div><br></div><div>The reason being is because I have an application that =
uses pseudorandom IDs for the JSON-RPC calls, and I'm trying to make sure t=
hat Core isn't going to send me someone else's JSON-RPC response if somebod=
y else happens to be making a request with that ID at the same instant, whi=
ch could be a potential security issue.</div><div><br></div><div>So far I d=
on't have any leads on the Github codebase yet, but I'm still looking.</div=
><div><br></div><div>Anyway I would appreciate if someone would clarify thi=
s topic for me.</div><div><br></div><div>---</div><div>Ali</div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" 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" rel=3D"n=
oreferrer nofollow noopener" target=3D"_blank">bitcoindev+unsubscribe@googl=
egroups.com</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/a358aaac-62d5-4d30-a599-40c94da66c4fn%40googlegroups.=
com" rel=3D"noreferrer nofollow noopener" target=3D"_blank">https://groups.=
google.com/d/msgid/bitcoindev/a358aaac-62d5-4d30-a599-40c94da66c4fn%40googl=
egroups.com</a>.<br>
</blockquote>
        </blockquote><br>
    </div>
        </blockquote><br>
    </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/5U7FixH_a7lxjcGGxLi5i-XRPXSVQfMyFHyEfwI532OTI1NoGUkD1=
s8Is3lEj07bL_1znuiEUwRfd7RNTdsA0kRLcRP1BNBZznHDD3YY0Sw%3D%40notatether.com?=
utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/b=
itcoindev/5U7FixH_a7lxjcGGxLi5i-XRPXSVQfMyFHyEfwI532OTI1NoGUkD1s8Is3lEj07bL=
_1znuiEUwRfd7RNTdsA0kRLcRP1BNBZznHDD3YY0Sw%3D%40notatether.com</a>.<br />

--b1_dz10CEF07ZpdMXeDwRZ6FMRamKxfAOMlSbx367YKGE--