Open code423n4 opened 2 years ago
I'm not sure I agree with this as an issue -- the relayers are whitelisted (to prevent generalized front-running, and limiting relayers to reliable relay networks).
Usually any dusting systems like the reimburseRelayerFees
do not have sybil resistance (unless you connect your socials or something similar), and this is something we will have to advertise to the people who create and fund the vault.
NOTE: inspiration for this feature was taken from existing nomad dusting, which has the same potential shortcomings, see here. Generally, chains have been willing to fund these vaults even with these drawbacks. That being said, balance checks could be added to add some slight guardrails!
I actually agree with the warden here. This type of attack would not be recognisable and could be disguised as general protocol activity. However, users' funds are not at direct risk, but sponsors' funds who intentionally give up these funds would be at risk of leaking value. Downgrading to medium
risk.
Lines of code
https://github.com/code-423n4/2022-06-connext/blob/b4532655071566b33c41eac46e75be29b4a381ed/contracts/contracts/core/connext/helpers/SponsorVault.sol#L234-L263
Vulnerability details
Impact
Sponsor vaults drained
Proof of Concept
reimburseRelayerFees uses SponsorVault funds to repay users the fees they pay to relayers. A malicious relayer could create a large number of transactions with the max reimbursed relay fee specified in SponsorVault between chains for which they relay all of them. They would receive back the relay fee from the SponsorVault and they would also get the relay fee they paid themselves.
Tools Used
Recommended Mitigation Steps
I don't see any way to mitigate this without substantial changes to the functionality of SponsorVault. Teams deploying SponsorVaults should be informed of potential misuse and set reimburse limits accordingly.