operate() does not check illegal revenueContract

[code423n4]

Lines of code

https://github.com/debtdao/Line-of-Credit/blob/e8aa08b44f6132a5ed901f8daa231700c5afeb3a/contracts/utils/SpigotLib.sol#L61

Vulnerability details

Impact

SpigotLib#operate() has check if the method signature in data is in the whitelist, but not check revenueContract is in settings[].
There is a certain risk that the signatures are the same, and operator can pass revenueContract=claimedToken, which is used to manipulate the claimedToken

Proof of Concept

    function operate(SpigotState storage self, address revenueContract, bytes calldata data) external returns (bool) {
        if(msg.sender != self.operator) { revert CallerAccessDenied(); }
        
        // extract function signature from tx data and check whitelist
        bytes4 func = bytes4(data);

        if(!self.whitelistedFunctions[func]) { revert BadFunction(); }
        
        if(
          func == self.settings[revenueContract].claimFunction ||
          func == self.settings[revenueContract].transferOwnerFunction
        ) { revert BadFunction(); }

        //****@audit don't check revenueContract legal？ ****//


        (bool success,) = revenueContract.call(data);
        if(!success) { revert BadFunction(); }

        return true;
    }

Tools Used

Recommended Mitigation Steps

    function operate(SpigotState storage self, address revenueContract, bytes calldata data) external returns (bool) {
        if(msg.sender != self.operator) { revert CallerAccessDenied(); }
        
        // extract function signature from tx data and check whitelist
        bytes4 func = bytes4(data);

        if(!self.whitelistedFunctions[func]) { revert BadFunction(); }
        
+       require(self.settings[revenueContract].transferOwnerFunction != bytes4(0),"invald revenueContract");

    }

[c4-judge]

dmvt marked the issue as duplicate of #71

[c4-judge]

dmvt marked the issue as satisfactory

[C4-Staff]

liveactionllama marked the issue as not a duplicate

[C4-Staff]

liveactionllama marked the issue as duplicate of #312