Open hats-bug-reporter[bot] opened 1 month ago
It is related to prover's implementation which will have amount filtration
It is related to prover's implementation which will have amount filtration
@party-for-illuminati , could you please provide a brief explanation of what "amount filtration" means in this context? I'm not entirely sure what you are referring to and would appreciate some clarification.
It is related to prover's implementation which will have amount filtration
@party-for-illuminati , could you please provide a brief explanation of what "amount filtration" means in this context? I'm not entirely sure what you are referring to and would appreciate some clarification.
Relayer won't prove transactions with amount lower than X where X is a configured minimum which is also considered on the frontend side, there is no need to fix it on the contracts side in my opinion
hey @party-for-illuminati ,Thank you for your prompt response.However, I believe addressing this issue at the contract level is still necessary for the following reasons:
it's crucial to assume that not all
interactions will go through the intended frontend or relayer. Users or malicious actors might interact directly with the contract. By enforcing a minimum donation amount within the contract, we ensure that the contract remains secure regardless of how it is accessed.
Relying solely on the relayer and frontend configurations for security introduces a single point of failure. If these layers are compromised or misconfigured, the contract remains vulnerable.
Configurations and frontend implementations can change over time, and there’s always a risk of human error during updates. By embedding the minimum donation logic within the contract, It make the security measure immutable
While the relayer and frontend configurations are valuable, they should complement, not replace
, contract-level security measures.and let's also not forget that the frontend can also or maybe bypassed by attacker
I hope this clarifies the importance of addressing the issue at the contract level. I look forward to your thoughts on this matter.
@party-for-illuminati ??
hey @party-for-illuminati ,waiting for the reply.
Github username: -- Twitter username: -- Submission hash (on-chain): 0xc6f3fc92b4ede91995efb1020a529da3caf78471916dc793232644a62044d197 Severity: medium
Description: Description\ The
_onActionDeposit
function in theVaultBitcoinWallet
contract is vulnerable to a Denial of Service attack. A malicious actor can exploit this vulnerability by sending a very small amount of Bitcoin such that thevalue
is equal to or less than the sum ofprotocolFees
andimportFees
.This can cause the function to revert, now due to this small donation attack,The
prover
will be unable to process legitimate deposits due to repeated reversion in the_onActionDeposit
function.Attack Scenario\
Attacker Sends Small Donation: The attacker sends a
Bitcoin
deposit with a value that is less than or equal to the sum ofprotocolFees
andimportFees
. For instance, ifprotocolFees
is1000
satoshis andimportFees
is500
satoshis, the attacker sends a deposit of1500
satoshis or less.Prover Calls processDeposit: The
prover
calls theprocessDeposit
function in theBitcoinAbstractWallet
contract to verify and process the transaction. TheprocessDeposit
function internally calls_processDeposit
, which then calls_onActionDeposit
.Function Reversion: Inside
_onActionDeposit
, thevalueAfterFees
calculation results inzero
or a negative value. This causes the subsequent operations, such as minting tokens and executing hooks, tofail
, leading to the function reverting.DoS Attack: The attacker repeatedly sends such small deposits, causing the
_onActionDeposit
function to revert each time.This prevents the prover from processing legitimate deposits
, effectively leading to a DoS attack.Attachments
Proof of Concept (PoC) File
Revised Code File (Optional)