Closed code423n4 closed 1 year ago
Would argue this would be Self-Inflicted, so am thinking QA
This is technically correct. However, we see this similar to Ethereum address. I can send ETH today with Metamask to an address that might not exist.
Even if we would check if the driver exists it doesn't imply that the Driver can handle a specific subAccount of this userID.
Recommendation: Not an Issue
[dispute validity] What Manuel said.
CodeSandwich marked the issue as sponsor disputed
GalloDaSballo changed the severity to QA (Quality Assurance)
GalloDaSballo marked the issue as grade-b
Lines of code
https://github.com/code-423n4/2023-01-drips/blob/9fd776b50f4be23ca038b1d0426e63a69c7a511d/src/DripsHub.sol#L409 https://github.com/code-423n4/2023-01-drips/blob/9fd776b50f4be23ca038b1d0426e63a69c7a511d/src/DripsHub.sol#L515 https://github.com/code-423n4/2023-01-drips/blob/9fd776b50f4be23ca038b1d0426e63a69c7a511d/src/DripsHub.sol#L576
Vulnerability details
Impact
Receiver's funds might be collected by any user or wouldn't be collected forever.
Proof of Concept
Currently, users can set any receivers in
DripHub.give(), setDrips(), setSplits()
functions.But actually, there is a driver limit which is increasing one by one in
registerDriver()
.So if the receiver's driver id is greater than this
nextDriverId
, it means the receiver doesn't have his driver yet and his driver can be set randomly. So the user who registers that dirver id will collect the funds.Also, if the driver id is too high like
type(uint32).max
, it's almost impossible to register such a driver id and the funds can't be collected forever.Tools Used
Manual Review
Recommended Mitigation Steps
I suggest we should validate that the receiver's driver id is registered already for the above 3 functions.