Closed code423n4 closed 1 year ago
I'd say QA Low
Technically, correct. Severity debatable.
[dispute validity]
The protocol allows dripping to any user ID whatsoever, it's up to the sender to make the right decision. In the current setup user ID 0x00..00
does indeed point at AddressDriver and a user ID managed by address 0x00..00
, but it's a coincidence. The app is out of scope, but thank you for finding the bug, I'll forward it.
CodeSandwich marked the issue as sponsor disputed
GalloDaSballo changed the severity to QA (Quality Assurance)
Caller can self-rekt, downgrading to QA per: https://github.com/code-423n4/org/issues/53
GalloDaSballo marked the issue as grade-c
Lines of code
https://github.com/code-423n4/2023-01-drips/blob/9fd776b50f4be23ca038b1d0426e63a69c7a511d/src/AddressDriver.sol#L122-L147
Vulnerability details
Impact
When setting a drip, it is possible to add null address (0x0) to receivers list. It shouldn't be a problem, except for the fact that the streamed tokens will be burned.
But it may (and it does in the beta front end version) break the front end of the streamer and of ALL THE OTHER RECEIVERS of the user who dripped toward 0x0.
In the current beta version of the frontend (https://beta.drips.network/app/dashboard), it can be used to DOS any address and prevent this address to use the front end.
Maybe the vulnerability is only in the current beta front end and not in the solidity code, but I think it should be prevented by the solidity code to prevent this kind of behavior to happen.
Proof of Concept
1) Open https://beta.drips.network/app/dashboard and connect with address A
2) Fund then add a drip to an address B
3) add a drip to adress 0x0000000000000000000000000000000000000000
4) Both address A and B can't use the font end anymore (B is DOSed from using the font end)
Tools Used
Manual testing
Recommended Mitigation Steps
Filter 0x0 address from receivers list or revert when it's in the list