Shardeum validator nodes implemented in the https://github.com/shardeum/shardeum
repository are vulnerable to complete DOS due to lack of input validation in repair_oos_accounts (https://github.com/shardeum/shardus-core/blob/4d75f797a9d67af7a94dec8860220c4e0f9ade3c/src/state-manager/AccountPatcher.ts#L336) and
repairMissingAccountsBinary (https://github.com/shardeum/shardus-core/blob/4d75f797a9d67af7a94dec8860220c4e0f9ade3c/src/state-manager/AccountPatcher.ts#L489) internal endpoints.
Exploitation leads to a complete stall of all of the active validator node's processes,
and due to the simplicity of the exploit, it is possible to execute it on all active nodes.
A more sophisticated attack would involve shutting down only a large part of the nodes, but not all,
for attacker-controlled nodes to be the only ones available, which can then be used to overtake the whole network.
In repairMissingAccountsBinary and repair_oos_accounts handlers, there is a loop that iterates up to receivedBestVote.account_id.length
https://github.com/shardeum/shardus-core/blob/4d75f797a9d67af7a94dec8860220c4e0f9ade3c/src/state-manager/AccountPatcher.ts#L413
for (let i = 0; i < receivedBestVote.account_id.length; i++) {
if (receivedBestVote.account_id[i] === accountID) {
if (receivedBestVote.account_state_hash_after[i] !== calculatedAccountHash) {
nestedCountersInstance.countEvent('accountPatcher', `repair_oos_accounts: account hash mismatch for txId: ${txId}`)
accountHashMatch = false
} else {
accountHashMatch = true
}
break
}
}
The issue arises from the fact that receivedBestVote is a request parameter and is not validated to be an array, which allows an attacker to pass the following object as part of the request data:
"appliedVote":sign({
"node_id":NODE_ID,
"transaction_result":"result",
"account_id":{
length: 10000000000000000000000000000000000000000000
}
})
This will cause NodeJS to go into an infinite loop because the value 10000000000000000000000000000000000000000000 is greater than Number.MAX_SAFE_INTEGER.
Due to how NodeJS works, this will block the process' event loop thread, and no other logic will be able to run, practically shutting the validator node down and making it simply infinitely waste CPU cycles.
The most basic outcome would be a total network shutdown caused by exploiting the DOS vulnerability on each active validator node. Since exploitation does not cause the nodes' processes to actually shut down or crash, the whole network will just stop processing any requests and user transactions. So that actually starting the network back up would require a fix to be deployed to all nodes, making it more difficult to mitigate.
A more complex attack scenario, as said in the intro, would be the shutdown of nearly all, but not all, validator nodes, so that attackers nodes would be the only ones left available. Which would leave the whole network to be controlled by the attacker. This means the network will continue functioning, but the attacker will be able to execute any transaction they want, and drain all the funds to themselves.
JavaScript max and min safe-to-use number values: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER, https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MIN_SAFE_INTEGER