Bifrost risk of DoS
due to the increase in transactions and events to process
#45
Labels
3 (High Risk)
Assets can be stolen/lost/compromised directly
bug
Something isn't working
edited-by-warden
🤖_18_group
AI based duplicate group recommendation
sufficient quality report
This report is of sufficient quality
Lines of code
https://github.com/code-423n4/2024-06-thorchain/blob/main/bifrost/pkg/chainclients/shared/evm/smartcontract_log_parser.go#L166
https://github.com/code-423n4/2024-06-thorchain/blob/main/bifrost/pkg/chainclients/shared/evm/utils.go#L12-L21
Vulnerability details
Description
By removing the
whitelisting
, Bifrost will be exposed to adramatic increase in traffic
, which translate in much more CPU / RAM and might be hard to keep up the load, which could translate in transactions delay/failures and crash from the Bifrost daemon ifself, so a risk ofDOSing the chain
, as without Bifrost working properly, THORChain doesn't work, which seems to warrantHigh
severity.I'm gonna do the case for the ETH mainnet only, but then we must also consider the other blockchain being supported so BSC and AVAX at least. Bifrost doesn't seem currently arquitected to run on multiple machines for a single operator, and even in K8s Bifrost will always have a single pod to represent a node operator as far as I understand.
Daily ETH transaction is sitting at around
1.2M
. If we account that about 1M transactions failure occur per month, that means on a daily basis about 33k transaction fails, so about3% are failures
, while97% are success
.THORChain Router on ETH is receiving about
2000 tx per day
which generates one event per transaction usually. This means the Bifrost will be callingETHScanner::getTxInFromSmartContract
that amount of time in the moment (and processing usually only a single event in GetTxInItem). Here is the issue. Once the whitelisting is removed, ALL the successful smart contract call on ETH that have emitted at least one event will now be calling this function.This translate in the function
ETHScanner::getTxInFromSmartContract
(which includeSmartContractLogParser::GetTxInItem
) being called much more often, we are talking here about a581x increase
in terms of load. That is for transaction only, then many will have multiple events (but those will be cut early in the loop). This is the worst case scenario as considering all the successfull transaction to have emitted at least one event, which might not be always the case.((1.2M * 0.97) / 2000) - 1 = 581x
Since the whole goal is to observe only the event emitted by the router,
most of the processing here will be simply wasted
, as of the 1.2M calls, only 2k would have such events (so 0.15% only).Impact
Risk of Bifrost being DoS
depending how much transactions supported EVM are generating. For example, someone that would like to DoS Bifrost could go on the cheapest supported chain, create a smart contract that do simply post dummy events to just hit the limit of event supported (which is configured to be50
), and do this as much as possible. Or a very popular dApp on the supported chain could inadvertently DoS Bifrost if their smart contract become very popular and emit a lot of events but not beyong the threshold.Recommended Mitigation Steps
While the current Bifrost implementation is working with fine whitelisting, there is a
realistic chance
that it would not be working as smooth without whitelisting for the amount of load increase explained in this report.There is a
much more efficient
way to retreive logs from a specific contract and this is using FilterQuery.While my report is not prooving for sure that Bifrost would be DoS due to load increase (which means also THORChain itself, as without Bifrost, THORChain will not function properly), but we can understand that there is a
real concern
about it, it is not future proof and the current way of observing transaction on connected blockchain isinefficient
, and I would highly recommend todo benchmark before going live with the current implementation, and probably implement a better observing mechanism as proposed here.Assessed type
DoS
The text was updated successfully, but these errors were encountered: