Camp security record

Token access can be bought via the marketplace according to the conditions outlined in the token `terms`. These terms can be updated by the token owner at any point using the `updateTerms()` function. Despite classical frontrunning being mitigated by the private mempool of the Camp network, this can be exploited by speculatively or accidentally frontrunning a call to `buyAccess()` and changing the subscription price, duration, or payment token. Payment can be made in either native or wrapped wCAMP tokens. In the case of wrapped tokens, the `buyAccess()` function in the marketplace does not check if native tokens were sent as well. If the payment token is changed to use wCAMP before the buy operation is executed, the transaction may consume both native and wrapped assets if the marketplace has sufficient approval for payment in wrapped tokens. The transaction will not revert, and the native tokens are lost in the marketplace. Similarly, the duration of the subscription could be lowered to extract more value per timeframe, or the price updated to the current approval between buyer and marketplace. Finally, when purchasing with ERC-20 tokens, the `_routeTokenPayment()` function transfers tokens directly from the buyer. IP owners may be able to expect incoming buy transactions, and exploit them by calling `updateTerms()` to increase the price to match the buyer's full token approval, effectively stealing all approved tokens rather than just the expected subscription price.

The token owners receive royalty payments for subscriptions, and may also be rewarded for dispute settlements. These rewards are paid to the token owner, but not directly to avoid DoS attack vectors. Instead, each token owner is supposed to have a `RoyaltyVault` contract to receive these funds. These contracts are currently created during the minting process. However, when a token is transferred to a new owner, they may not have a vault registered in the `royaltyVaults` mapping. In this case, royalty payments will be transferred to the zero address, resulting in a loss of funds due to the following code: ``` solidity if (token == address(0)) { SafeTransferLib.safeTransferETH(ipToken.royaltyVaults(recipient), share); } else { SafeTransferLib.safeTransferFrom(token, payer, ipToken.royaltyVaults(recipient), share); } ``` Furthermore, there's no way for the new owner or the contract owner to create and register a vault to solve this issue.

This fork of the Synthetix `StakingRewards` contract introduces a `unstakeDelay` variable that is intended to enforce a minimum duration between `stake` and `withdraw` operations. For this purpose the contract records the last deposit timestamp for each user. However, the `stake()` function can be executed by a delegator, and does not require a minimum deposit. This way a user can stake a small amount on behalf of another user before their `unstakeDelay` passes, extending the lock and thus blocking them from withdrawing their tokens.

The `batchRelease()` function in `CampTimelockEscrowNativeOFT` processes deposits sequentially in a loop. When processing each deposit, it calls `_bridgeNativeTokens()`, which internally triggers LayerZero's dust removal mechanism via `_removeDust()`. This function rounds down the amount by removing decimal precision dust to ensure compatibility across chains with different token decimals. However, a malicious user can exploit this mechanism by setting a `_minAmount` parameter that becomes incompatible with the dust-adjusted amount. The LayerZero `OFTCore` contract performs a slippage check that reverts if the dust-adjusted amount falls below the user-specified `_minAmount`: ```solidity // In OFTCore._debitView() amountSentLD = _removeDust(_amountLD); amountReceivedLD = amountSentLD; // Check for slippage - this will revert if dust removal reduces amount below minAmount if (amountReceivedLD < _minAmountLD) { revert SlippageExceeded(amountReceivedLD, _minAmountLD); } ``` When this revert occurs during the `batchRelease` loop, it causes the entire transaction to revert. Since deposits are processed sequentially and there's no error handling around individual deposit processing, a single malicious deposit can permanently block the processing of all subsequent deposits in the queue, effectively creating a Denial of Service condition. Another simpler attack could be that `minAmount` is simply larger than the `_originalAmount`, and since there is no validation, it will always fail too. The fix with dust adjusted value should fix both scenarios.

The `bridgeOut()` function acts as the deposit entrypoint to the OFT bridge. It is supposed to receive native tokens, which are later bridged. The amount of tokens to be bridged is provided by the user with the `_originalAmount` parameter, however it is never verified against the actual supplied `msg.value`. This allows users to effectively initiate a bridging operation with debt, which then consumes tokens provided by other depositors. This is particularly exploitable by whitelisted users, who can drain the contract immediately. Other users cannot affect already initiated deposits, and only misuse tokens from those initiated after the malicious one. This could be exploited in combination with frontrunning to steal funds while ensuring that sufficient funds are available for the validations in the `send()` function. Alternatively, creating a deposit with very high debt would effectively DoS the bridge as a whole, as this deposit cannot be skipped in the `batchRelease()` function.

The `send()` operation incurs additional fees exceeding the `_originalAmount` recorded during the initial deposit using the `bridgeOut()` function. This total value is calculated in the `_bridgeNativeTokens()` functions, and then paid from the contract balance. However, there is no validation that this fee is paid during the initial deposit. In its current form, the contract may run out of funds while still having unprocessed queued deposits.

Token terms designate the conditions for buying access and minting derivative tokens. The input validation for these values is very lax, therefore extreme values can be assigned with potentially unintended consequences. 1. The price can be set to 0. In this case parents do not receive royalties anymore. This may be exploitable by creating derivative tokens to offer similar content as the original at a much lower price. Similarly, a very high price will make subscriptions impossible. 2. The duration can be set very low, for example 1 second. This would make subscription management near impossible, as access can only be bought for 1 period at a time. 3. Setting the royalty fee to 100% blocks the creation of derivative tokens, as a fee of 0 is invalid and the total must not be higher than 100%. Even other, very high values may make the creation of derivative tokens with multiple parents very challenging. ``` solidity if (newTerms.duration == 0) revert InvalidDuration(); if (newTerms.duration > maxTermDuration) revert InvalidDuration(); if (newTerms.royaltyBps == 0 || newTerms.royaltyBps > LibBPS.DENOMINATOR) revert InvalidRoyalty(); if (newTerms.paymentToken != address(0) && newTerms.paymentToken != wCAMP) revert InvalidPaymentToken(); ```

Any token can have up to 8 parent tokens, whose owners receive a share of all generated profit. This revenue split is set in stone during the minting process according to the royalty terms of the involved tokens. The `RoyaltyModule` ensures that the total sum of royalties does not exceed 100%. If however the total is less than 100%, the token owner of a listed parent is incentivized to frontrun the minting transaction to maximize their royalty. It may therefore seem reasonable to suggest users to ensure that all relevant royalties add up to 100%, but this may not be desired by the minter to ensure usability for derivative tokens.

The `bridgeOut()` and `release()` functions allow the caller to specify a `_gaslimit` argument. This value is the maximum amount of gas units the executor should use on the destination chain when completing the bridge. However, in the case of the `CampTimelockEscrow` contract, there is never any validation that some minimum amount of gas is available on the destination chain to ensure the bridge transaction is successful. Therefore, User A could process User B's deposit via the `release()` function, specifying a very small `_gaslimit`, causing the transaction to fail on the destination chain. This means the affected user would have directly to call the `lzReceive()` function on the target chain's implementation of the Camp OFT contract in order to complete their bridge action successfully.

This escrow bridge relies on a queue to manage deposits. All new deposits are appended to the queue and share the same `holdPeriod` before the bridging operation can commence. The queue is checked and consumed using the `batchRelease()` function, which increments a global cursor indicating the cutoff index of processed deposits in the queue. For each batch, some supplied maximum amount of entries is checked, bridging deposits where the `unlockTimestamp` has passed. No deposits in the queue can be skipped, and the `bridgeOut()` function is likely substantially cheaper in gas than the `send()` function and does not enforce a minimum deposit. Therefore, small deposits could be use to extend the size of the queue substantially, requiring someone to pay the gas cost of initiating all those bridging transactions using the `batchRelease()` function before any deposits later in the queue can be executed.