forked from somatic-labs/meteorite
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathNew finding_ malformed txns never leave mempool.eml
64 lines (52 loc) · 3.13 KB
/
New finding_ malformed txns never leave mempool.eml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
MIME-Version: 1.0
Date: Sun, 8 Oct 2023 09:27:17 +0300
Message-ID: <CAK5+0FT48fsLMDSi8uQLfTiy9N0-UOBYtUhfSFVQhyQ+i2vwag@mail.gmail.com>
Subject: New finding: malformed txns never leave mempool
From: Jacob Gadikian <[email protected]>
Khanh Nguyen <[email protected]>, Alex Sutaru <[email protected]>,
Joe Bowman <[email protected]>, Sheldon Dearr <[email protected]>
Content-Type: multipart/alternative; boundary="000000000000ad91f406072e90b9"
--000000000000ad91f406072e90b9
Content-Type: text/plain; charset="UTF-8"
I realize that in the present state people aren't actually in the habit of
looking at the repository that we created, but if you see in there there's
a file called mempoolcryptocrew.json.
That contains these, I think.
In order to understand the attack I strongly recommend running it.
Below are Joe's findings
```
@Jacob Gadikian another (albeit reasonably minor) bug - note untested, just
from reading the mempool code:
Notably, the both of these values (checkTx and txPreFilter) use the raw
value of MaxBytes, but should - for correctness - use types.MaxDataBytes()
to ensure the total block size remains within the correct bounds. Failure
to use the correct value allows a malicious actor to fill a network's
mempool with transactions of size `types.MaxDataBytes > x > MaxBytes` which
can never be delivered (as they will never be picked up by ReapMaxTxBytes -
which does use the correct value),.
```
--000000000000ad91f406072e90b9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div dir=3D"auto"><br></div><div dir=3D"auto">I realize t=
hat in the present state people aren't actually in the habit of looking=
at the repository that we created, but if you see in there there's a f=
ile called mempoolcryptocrew.json.=C2=A0</div><div dir=3D"auto"><br></div><=
div dir=3D"auto">That contains these, I think.=C2=A0</div><div dir=3D"auto"=
><br></div><div dir=3D"auto">In order to understand the attack I strongly r=
ecommend running it.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Bel=
ow are Joe's findings</div><div dir=3D"auto"><br></div><div dir=3D"auto=
">```</div><div dir=3D"auto"><br></div>@Jacob Gadikian another (albeit reas=
onably minor) bug - note untested, just from reading the mempool code:<div =
dir=3D"auto"><br></div><div dir=3D"auto">Notably, the both of these values =
(checkTx and txPreFilter) use the raw value of MaxBytes, but should - for c=
orrectness - use types.MaxDataBytes() to ensure the total block size remain=
s within the correct bounds. Failure to use the correct value allows a mali=
cious actor to fill a network's mempool with transactions of size `type=
s.MaxDataBytes > x > MaxBytes` which can never be delivered (as they =
will never be picked up by ReapMaxTxBytes - which does use the correct valu=
e),.</div><div dir=3D"auto"><br></div><div dir=3D"auto">```</div><div dir=
=3D"auto"><br></div><div dir=3D"auto"><br></div></div>
--000000000000ad91f406072e90b9--