code-423n4 / 2023-06-canto-findings

1 stars 0 forks source link

Whitelisted channel check uses the destination channel instead of the source channel #18

Closed code423n4 closed 1 year ago

code423n4 commented 1 year ago

Lines of code

https://github.com/code-423n4/2023-06-canto/blob/a4ff2fd2e67e77e36528fad99f9d88149a5e8532/Canto/x/onboarding/keeper/ibc_callbacks.go#L47

Vulnerability details

Impact

According to the comment that documents the whitelisted channel check, the source channel from where the packet was sent is checked to ensure the channel is whitelisted thus the onboarding process can occur. This makes sense since the destination channel is where the IBC callback itself is executed when a packet is received (Canto). The actual code though checks against the destination channel (packet.DestinationChannel instead of packet.SourceChannel).

Subsequently the onboarding process can occur for unauthorized channels only instead of the intended authorized channels. The impact of this is that the intended connection from the Gravity Bridge will not onboard end users properly. It does not look like there is any sort of financial risk since there is only a specific set of IBC assets that can be used and a user of an unauthorized channel would have to spend those assets in order to swap and get onboarded in Canto.

Tools Used

VSCode, Go

Recommended Mitigation Steps

Change packet.DestinationChannel to packet.SourceChannel here. The unit test related to the unauthorized channel check also needs to be fixed. It is also recommended to ensure the names of the source and destination channels are different in the unit tests which is good practice to avoid subtle issues in the tests that may paper over vulnerabilities.

Assessed type

Access Control

c4-pre-sort commented 1 year ago

JeffCX marked the issue as duplicate of #53

c4-judge commented 1 year ago

0xean marked the issue as unsatisfactory: Invalid