-
Notifications
You must be signed in to change notification settings - Fork 219
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: miner delay attack #5582
fix: miner delay attack #5582
Conversation
Is it possible to label this PR to reflect its status as an audit fix? It should be easy for interested researchers and developers to quickly find audit-related fixes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is not a bad start.
- I like doing the reconcile before the semaphore, but I think you should remove the semaphore entirely since it no longer serves a purpose.
- This solution introduces another problem, as @sdbondi noted, we will be requesting many blocks. I suggest only doing one reconcile per block hash. This could be done using a hashmap/set in this file, or potentially even in
base_node_service.rs::spawn_handle_incoming_block
and only spawning a thread if there is no thread currently handling this blockhash
I disagree about removing the semaphore, after this point, we are making changes to the tip, and rely on the tip to stay constant during the process. |
37c01a2
to
3f570ed
Compare
base_layer/core/src/base_node/comms_interface/inbound_handlers.rs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An attacker may still delay the reconciliation if it is the first message, in the worst case making the base node switch to BlockSync mode. This may be fine as an attacker would need to be the first message in, and we assume they have no control over that.
The hash removal also needs to be done in the error case.
base_layer/core/src/base_node/comms_interface/inbound_handlers.rs
Outdated
Show resolved
Hide resolved
base_layer/core/src/base_node/comms_interface/inbound_handlers.rs
Outdated
Show resolved
Hide resolved
base_layer/core/src/base_node/comms_interface/inbound_handlers.rs
Outdated
Show resolved
Hide resolved
base_layer/core/src/base_node/comms_interface/inbound_handlers.rs
Outdated
Show resolved
Hide resolved
base_layer/core/src/base_node/comms_interface/inbound_handlers.rs
Outdated
Show resolved
Hide resolved
base_layer/core/src/base_node/comms_interface/inbound_handlers.rs
Outdated
Show resolved
Hide resolved
2f010e8
to
1d0a4a6
Compare
base_layer/core/src/base_node/comms_interface/inbound_handlers.rs
Outdated
Show resolved
Hide resolved
6a7db77
to
ac95868
Compare
base_layer/core/src/base_node/comms_interface/inbound_handlers.rs
Outdated
Show resolved
Hide resolved
99edeff
to
0b57384
Compare
0b57384
to
0b721c5
Compare
Co-authored-by: Stan Bondi <[email protected]>
0b721c5
to
5b6e6e7
Compare
…-addresses * development: chore: fix windows install (tari-project#5616) feat: ban peer unexpected response (tari-project#5608) fix!: add validator mr to mining hash (tari-project#5615) fix: check bytes remaining on monero blocks (tari-project#5610) fix: duplicate tari header in monero coinbase (tari-project#5604) fix: monero fork attack (tari-project#5603) feat: add mempool min fee (tari-project#5606) chore(tests): large block unit tests (tari-project#5599) fix: miner delay attack (tari-project#5582) fix: peer connection to stale nodes (tari-project#5579) ci(fix): artifact cleanup for diag-utils (tari-project#5613) ci(fix): update Windows installer for Minotari (tari-project#5614) chore: fixes monero build (tari-project#5612)
Description
Stops the node blocking until it has a full block
Audit Finding Number
TARI-0001, TARI-0002
Motivation and Context
Its possible for a malicious node to block access to the full block by using first the mempool to say it does not have the missing transactions, then when asked for the full block to only then provide the full block. But these requests can be made slow to delay the node constructing the new block by almost 2 mins. This is the block time.
By only accepting 1 block request at a time, a malicious node can lock down the local node for that entire 2 mins knowing they wont accept any other blocks. This changes it so that nodes can still process new requests. The first complete block will be served first.
Also changes the display of block information to ensure block sorted is correctly used.