Closed code423n4 closed 1 year ago
minhquanym marked the issue as primary issue
CJ42 marked the issue as sponsor disputed
We do not consider this a valid issue. If you send to the wrong receiver address (e.g: the LSP1 Delegate address), this is a wrong parameter provided to the function.
trust1995 marked the issue as unsatisfactory: Invalid
Lines of code
https://github.com/code-423n4/2023-06-lukso/blob/main/contracts/LSP1UniversalReceiver/LSP1UniversalReceiverDelegateUP/LSP1UniversalReceiverDelegateUP.sol#L259-L265
Vulnerability details
Bug Description
Contracts that implement the LSP-1 standard include
_INTERFACEID_LSP1
in theirsupportsInterface()
function. This means that they have auniversalReceiver()
function that calls a Universal Receiver Delegate (URD), such asLSP1UniversalReceiverDelegateUP
.LSP0ERC725Account
is an example of a URD caller:LSP0ERC725AccountCore.sol#L704
Similarly, URDs are also expected to include
_INTERFACEID_LSP1
in theirsupportsInterface()
function, such asLSP1UniversalReceiverDelegateUP
:LSP1UniversalReceiverDelegateUP.sol#L259-L265
Therefore, URD callers will check for
_INTERFACEID_LSP1
to determine if the address is a URD.LSP0ERC725AccountCore
'suniversalReceiver()
function is an example of this behavior:LSP0ERC725AccountCore.sol#L479-L493
However, this is an issue as there is no way to differentiate between URDs and their callers. This could potentially allow users to perform a transaction that requires a LSP-1 compatible contract on the receiving end, such a LSP7 token transfer, but with a URD as the receiver instead.
For example, a user could send LSP7 tokens to the
LSP1UniversalReceiverDelegateUP
contract, and the call would succeed as its contract supports_INTERFACEID_LSP1
and has auniversalReceiver()
function. However,LSP1UniversalReceiverDelegateUP
should not be able to receive LSP7 tokens as they will become stuck in the contract.Additionally, some contracts might allow URD contracts to call
setDataBatch()
and write into its storage (eg. LSP0 accounts give theLSP1UniversalReceiverDelegateUP
contractSUPER_SETDATA
andREENTRANCY
permissions). This could potentially lead to more serious impacts as URDs might unintentionally write into the storage of the calling contract.Impact
Due to the URDs and their callers sharing the same ERC-165 interface IDs, URDs can be set as the receiver for transactions that require LSP-1 compatibility.
However, as URD contracts have limited functionality, this could cause undesired effects, such as tokens getting stuck or contracts having data written into their ERC725Y storage unintentionally.
Proof of Concept
Consider the following example contract, which acts as a wrapper for LSP7 tokens:
Since it is meant to receive tokens, it allows
universalReceiverDelegate
(assume it is set asLSP1UniversalReceiverDelegateUP
) to callsetDataBatch()
. However, if a users transfer WRAP tokens directly to theLSP1UniversalReceiverDelegateUP
contract, this would lead to:universalReceiver()
function writing data intoLSP7Wrapper
's storage here.Recommended Mitigation
Consider having separate ERC-165 interface IDs for URDs and their callers, similar to how LSP17 has two different interface IDs for extensions and extendable contracts.
Assessed type
Invalid Validation