Delivery-date: Tue, 09 Apr 2024 17:28:52 -0700 Received: from mail-yw1-f184.google.com ([209.85.128.184]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1ruLpb-0008Lq-8A for bitcoindev@gnusha.org; Tue, 09 Apr 2024 17:28:52 -0700 Received: by mail-yw1-f184.google.com with SMTP id 00721157ae682-60cd62fa1f9sf96298807b3.0 for ; Tue, 09 Apr 2024 17:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1712708925; x=1713313725; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=pKpxauU65a//Wja4VqYRNZBUERAEInr2nHlYpcie9gw=; b=uJTvynTASE1BvuhO5cuBzzjcmKV5xsXENjs1sULCUoauHxtJv9zZPzUMPzHXdRcYsW 2HcgrA8vL+PKjPZQjN9RTXS46gqICu8xX4C3++YlnNPedJGdvrSjAZY/O/CLuhNGGWXL jBBeJBzr1Qh00r0N8sHhZG92FD6svzmg5ZHvO2zLc3MAIEANvLold2UeENPWeFTx4+xd KsbZ/hGWvd90d1ayFo4lxteOmrWBLoXiGA18cIrsdJIHQYVeeuYti+br0GbnmMAgZd+d zx1IEm9IX/s4Y74pn9JyQDulJNryMAm6b/QzULL0KrXE1C5/D9rt6RLONp+784drHtH9 BxZg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712708925; x=1713313725; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=pKpxauU65a//Wja4VqYRNZBUERAEInr2nHlYpcie9gw=; b=mZgd+Q3glR4uF6I4As5vN2Jt9gd2pHizw52km96r9kc7k3TlgEiEsl/LDzh0c06on4 xQVGINQP9sKQRtdb+J86W2qiqwmIymfm9Q9NJNrR2R/tCsDHG0QxXCsPyfM/978OFAiG WRJu6D96YVu2FlceiF8ZiT5DTFqUvwqW/jb2Vbeja+J/Er0spRJlSZuyAycFz8YD/yQr W+pM9ZgGfxKoiAnEWZ8pa59wrqxM+IDrDr3pcZtJYVMLcI0Njr4bRKze1Dk/uTNrhiqb kQqYihRNTWYOlMlsAuPD7i80Tyn73bUA22obZgE4n+37jNrAIXvZ0L8Vl6uEkWsH96t5 rvtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712708925; x=1713313725; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=pKpxauU65a//Wja4VqYRNZBUERAEInr2nHlYpcie9gw=; b=iEHWfp8xiTY8AONo6z1YABqosjTlXGe8e6o/qUzHDCEMf5upYTb74u0ZdwgNtogw0L FsWb3Myh7YMw8Pc/KyqmcvLG4OEGXpxyhvCUhx0SrnSlj5AbLPmdR7SnzxhRz0ZcCggT 2xGyBN67k8qp/AGjg74ocfISc1zIfa4TvuhS+pDqAkwgiaou9rPJJb70ZacWWfkCUkkh 8oHAwgVYWO9n1EX/nioT3S7DW0sIZvu/ajgogNA2c4MWD8mhoswypgGdR8YCp+brQFmL rWhhahUALICvorQOwkrpzTRFb6r4SXco5EONmQ/QVG7v7L8wFRN5TD7/C4Fk00XeDXXX C7hg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCW8ARiMn8Ac/aBN/aA0qWy09EsShHAjy0nfaWIH2WYsH1QjtYwOCT0GxRjfPeoQ/+B7nVGqnkMM3i5lMdH3Qq7VqkVzVjc= X-Gm-Message-State: AOJu0YzHb8mVvCbIerzQVWNBj9335nA8bhZsrUesrPkngd/X0r5yJ+c1 SGDFEHaQ3Oy1ffeScqfWaAKihdN4YwTSNWLNsS5HdkvCWwfnp454 X-Google-Smtp-Source: AGHT+IEXlkyxSisuqm2TfVSlb1PH7MBq+gT3U8WXVNy8YnnYYwQ+KigAfDEiLhWmlbw6rsXavFZrwQ== X-Received: by 2002:a25:902:0:b0:dc2:3936:5fa5 with SMTP id 2-20020a250902000000b00dc239365fa5mr1292921ybj.51.1712708924981; Tue, 09 Apr 2024 17:28:44 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:72c4:0:b0:dcc:4b24:c0dd with SMTP id n187-20020a2572c4000000b00dcc4b24c0ddls212239ybc.0.-pod-prod-08-us; Tue, 09 Apr 2024 17:28:43 -0700 (PDT) X-Received: by 2002:a25:d312:0:b0:dc6:f877:ea7b with SMTP id e18-20020a25d312000000b00dc6f877ea7bmr334768ybf.9.1712708923746; Tue, 09 Apr 2024 17:28:43 -0700 (PDT) Received: by 2002:a05:690c:dc6:b0:609:3e5d:63d0 with SMTP id 00721157ae682-61841304c15ms7b3; Tue, 9 Apr 2024 16:35:43 -0700 (PDT) X-Received: by 2002:a25:d312:0:b0:dc6:f877:ea7b with SMTP id e18-20020a25d312000000b00dc6f877ea7bmr309942ybf.9.1712705742541; Tue, 09 Apr 2024 16:35:42 -0700 (PDT) Date: Tue, 9 Apr 2024 16:35:42 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <74f23461-fae2-4dd7-9a20-5e6557cd1f2fn@googlegroups.com> In-Reply-To: <5U7FixH_a7lxjcGGxLi5i-XRPXSVQfMyFHyEfwI532OTI1NoGUkD1s8Is3lEj07bL_1znuiEUwRfd7RNTdsA0kRLcRP1BNBZznHDD3YY0Sw=@notatether.com> References: <5U7FixH_a7lxjcGGxLi5i-XRPXSVQfMyFHyEfwI532OTI1NoGUkD1s8Is3lEj07bL_1znuiEUwRfd7RNTdsA0kRLcRP1BNBZznHDD3YY0Sw=@notatether.com> Subject: Re: [bitcoindev] Security implications of using pseudorandom JSON-RPC IDs MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_17408_1687740009.1712705742175" X-Original-Sender: antoine.riard@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_17408_1687740009.1712705742175 Content-Type: multipart/alternative; boundary="----=_Part_17409_1775370888.1712705742175" ------=_Part_17409_1775370888.1712705742175 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ali, Bitcoin Core RPC protocol as documented in `src/rpc/protocol` RPCErrorCode= =20 does not commit to unique JSON RPC IDs towards applications. About metadata ids, Bitcoin Core's `WorkQueue` only knows about=20 `std::unique_ptr` which is a pointer itself, and as such should have a=20 unique virtual memory address assigned by your kernel to your `bitcoind`= =20 process. While indeed memory corruption *could* lead to resolve a RPC call= =20 pointer to another address of a `bitcoind`'s function, this is dependent on the binary compilation flags, among other things.=20 In the future, if you find memory corruption bugs in Bitcoin Core, even=20 benign in non-significant subsystems, thanks to communicate them with=20 sufficient technical description to security@bitcoincore.org or security=20 reporters you trust. If you don't have experience in security handling=20 disclosure, you can consult=20 https://bitcoinops.org/en/topics/responsible-disclosures/ or=20 Linux's https://docs.kernel.org/process/security-bugs.html#securitybugs Generally, I'll discourage to have multiple user-level applications sharing= =20 a common Bitcoin Core JSON-RPC on a single process instance, as soon as you= =20 have funds at stake, and when it''s not only for informational purpose like= =20 knowing chain state height (e.g block explorer) or features set available.= =20 There is no end-to-end encryption of the JSON RPC calls from user with corresponding key distribution protocol= =20 for endpoints. See `doc/JSON-RPC-interface.md` for more. Best, Antoine Le dimanche 7 avril 2024 =C3=A0 09:28:26 UTC+1, Ali Sherief a =C3=A9crit : > > I think the conversation did not get sent to the mailing list somehow.=20 > Still trying to get the hang of Google Groups I guess. Anyway I'm going t= o=20 > forward it here just to be sure. > > --- > Ali > ------- Forwarded Message ------- > From: Ali Sherief > Date: On Sunday, April 7th, 2024 at 7:47 AM > Subject: Re: [bitcoindev] Security implications of using pseudorandom=20 > JSON-RPC IDs > To: hashnoncemessage > > Using the RPC method 'getrpcinfo', I can't seem to produce a parallel RPC= =20 > evaluation, even though I am using 4 RPC threads. > > If anyone wants to reproduce, you can simulate asynchronous calls in Bash= =20 > 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=20 > which they get the RPC request from: ( > https://github.com/bitcoin/bitcoin/blob/0f0e36de5f53f82d31416dc05a24d2885= 781ce57/src/httpserver.cpp#L70-L125 > )=20 > > So as I understand it, the system doesn't actually make use of the=20 > JSON-RPC metadata such as id, but it's just distributing the work in the= =20 > queue to different threads. So it is not possible to use the id to corrup= t=20 > the work queue. > > However, what I did notice is that the internal evhttp_request variables= =20 > can (theoretically) be edited to resolve to a different pointer in order = to=20 > achieve the same effect, of receiving a different JSON reply. This would= =20 > require some form of memory corruption bug to be found in Bitcoin Core th= at=20 > affects some global data structure that comes close enough before=20 > g_work_queue or the queue itself, so for linux-gcc on x86 platforms at=20 > least, any of these variables: ( > https://github.com/bitcoin/bitcoin/blob/0f0e36de5f53f82d31416dc05a24d2885= 781ce57/src/httpserver.cpp#L141-L147 > ) > > But it would be more likely to cause a node crash than the intended=20 > result, I think. > > Obviously I'm not a security researcher but I do have a good grasp of C++= ,=20 > so just doing my due diligence to check what kind of attack vectors exist= =20 > in my program's dependencies. > > --- > Ali > > On Sunday, April 7th, 2024 at 6:33 AM, hashnoncemessage < > hashnonc...@proton.me> wrote: > > As I understand it, the json rpc server responds directly to the (http)= =20 > request initiated by the client.=20 > > Request IDs are used for correlation of different requests from the same= =20 > client.=20 > > Core will not send your client=E2=80=99s response to a different=20 > client/connection.=20 > > > On Sun, Apr 7, 2024 at 07:57, Ali Sherief wrote: > > I am trying to figure out how the Bitcoin Core RPC server stores the=20 > UniValue JSON-RPC requests. > > The reason being is because I have an application that uses pseudorandom= =20 > IDs for the JSON-RPC calls, and I'm trying to make sure that Core isn't= =20 > going to send me someone else's JSON-RPC response if somebody else happen= s=20 > to be making a request with that ID at the same instant, which could be a= =20 > potential security issue. > > So far I don't have any leads on the Github codebase yet, but I'm still= =20 > looking. > > Anyway I would appreciate if someone would clarify this topic for me. > > --- > Ali > > --=20 > You received this message because you are subscribed to the Google Groups= =20 > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to bitcoindev+...@googlegroups.com. > To view this discussion on the web visit=20 > https://groups.google.com/d/msgid/bitcoindev/a358aaac-62d5-4d30-a599-40c9= 4da66c4fn%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/74f23461-fae2-4dd7-9a20-5e6557cd1f2fn%40googlegroups.com. ------=_Part_17409_1775370888.1712705742175 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ali,

Bitcoin Core RPC protocol as documented in `sr= c/rpc/protocol` RPCErrorCode does not commit to unique JSON RPC IDs towards= applications.

About metadata ids, Bitcoin Core'= s `WorkQueue` only knows about `std::unique_ptr` which is a pointer itself,= and as such should have a unique virtual memory address assigned by your k= ernel to =C2=A0your `bitcoind` process. While indeed memory corruption *cou= ld* lead to resolve a RPC call pointer to another address of a `bitcoind`'s= function,
this is dependent on the binary compilation flags, amo= ng other things.=C2=A0

In the future, if you fin= d memory corruption bugs in Bitcoin Core, even benign in non-significant su= bsystems, =C2=A0thanks to communicate them with sufficient technical descri= ption to=C2=A0security@bitcoincore.org or security reporters you trust. If = you don't have experience in security handling disclosure, you can consult = https://bitcoinops.org/en/topics/responsible-disclosures/ or Linux's=C2=A0h= ttps://docs.kernel.org/process/security-bugs.html#securitybugs
Generally, I'll discourage to have multiple user-level appli= cations sharing a common Bitcoin Core JSON-RPC on a single process instance= , as soon as you have funds at stake, and when it''s not only for informati= onal purpose like knowing chain state height (e.g block explorer) or featur= es set available. There is no end-to-end encryption of
the JSON R= PC calls from user with corresponding key distribution protocol for endpoin= ts. See `doc/JSON-RPC-interface.md` for more.

Be= st,
Antoine

Le dimanche 7 avril 2024 =C3=A0 09:28:26= UTC+1, Ali Sherief a =C3=A9crit=C2=A0:

=20
=20
=20
I think th= e conversation did not get sent to the mailing list somehow. Still trying t= o get the hang of Google Groups I guess. Anyway I'm going to forward it= here just to be sure.

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

Using the RPC method 'ge= trpcinfo', I can't seem to produce a parallel RPC evaluation, even = though I am using 4 RPC threads.
If anyone wants to reproduce, yo= u can simulate asynchronous calls in Bash or another shell:

bitco= in-cli getblockchaininfo &
bitc= oin-cli getrpcinfo

The output of the second command on my machine= is:

{
=C2=A0 "active_commands":= [
=C2=A0 =C2=A0 {
=C2=A0 =C2= =A0 =C2=A0 "method": "getrpcinfo",
=C2=A0 =C2=A0 =C2=A0 "duration": 58
=C2= =A0 =C2=A0 }
=C2=A0 ],
=C2=A0= "logpath": "/home/zenulabidin/.bitcoin/debug.log"
}

I see th= at there is a global work queue shared by all the threads from which they g= et the RPC request from: (https://github.com/bitcoin/bitcoin/blob/0f0e36de5f53f= 82d31416dc05a24d2885781ce57/src/httpserver.cpp#L70-L125)=C2=A0

So as I understand it, the system doesn't a= ctually make use of the JSON-RPC metadata such as id, but it's just dis= tributing 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 t= o 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 that= affects some global data structure that comes close enough before g_work_q= ueue or the queue itself, so for linux-gcc on x86 platforms at least, any o= f these variables: (https://github.com/bitcoin/bitcoin/blob/0f0e36de5f53f82= d31416dc05a24d2885781ce57/src/httpserver.cpp#L141-L147)

=
But it would be more likely = to cause a node crash than the intended result, I think.

Obviously I'm not a security researcher but I do have a good grasp = of C++, so just doing my due diligence=C2=A0to check what kind of attack ve= ctors exist in my program's dependencies.

---
Ali

On Sunday, April 7th, 2024 at 6:33 AM, hashnoncemessage <hashnonc...@proton.me> wrote:
As I understand it, the json rpc server re= sponds directly to the (http) request initiated by the client.=C2=A0
<= div dir=3D"auto">
Request IDs are used for corre= lation of different requests from the same client.=C2=A0

Core will not send your client=E2=80=99s r= esponse to a different client/connection.=C2=A0

On Sun, Apr 7, 2024 at 07:57, Ali Sherief &l= t;a...@notat= ether.com> wrote:
= I am trying to figure out how the Bitcoin Core RPC server stores the UniV= alue JSON-RPC requests.

The reason being is because I ha= ve an application that uses pseudorandom IDs for the JSON-RPC calls, and I&= #39;m trying to make sure that Core isn't going to send me someone else= 's JSON-RPC response if somebody else happens to be making a request wi= th that ID at the same instant, which could be a potential security issue.<= /div>

So far I don't have any leads on the Github co= debase yet, but I'm still looking.

Anyway I wo= uld appreciate if someone would clarify this topic for me.

---
Ali

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitc= oindev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/a358aaac-62d5= -4d30-a599-40c94da66c4fn%40googlegroups.com.


--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/74f23461-fae2-4dd7-9a20-5e6557cd1f2fn%40googlegroups.com.=
------=_Part_17409_1775370888.1712705742175-- ------=_Part_17408_1687740009.1712705742175--