Unauthorized source channels have the potential to illicitly initiate the onboarding swap mechanism. This scenario not only poses a risk to the security of the Canto network, but it also raises questions about the integrity of asset transfers. In the event of such a violation, the seamless and secure swap and conversion of assets to Canto via IBC middleware could be compromised, potentially allowing for unwanted transactions.
Given the explicit design of the system to trigger these operations only through whitelisted channels, any activation through unauthorized channels undermines the fundamental architecture and security parameters of the system. Therefore, the potential for unauthorized source channels to instigate the onboarding swap is a significant concern that necessitates immediate attention and rectification.
Proof of Concept
According to the specification:
When assets are transferred to the Canto network via the Gravity Bridge, the IBC transfer naturally sets off a swap and conversion to Canto via the IBC middleware. These operations are activated only when the transfer is made through an approved channel.
Also:
WhitelistedChannels: These are channels authorized for automatic swap and conversion. If the channel isn't on this list, automatic swap and conversion won't take place. The default setting is ["channel-0"], a channel for Gravity Bridge.
The team created a video walk-through to review the system architecture:
// verify if the source channel is on the list of whitelisted channels
var found bool
for _, s := range params.WhitelistedChannels {
if s == packet.DestinationChannel {
found = true
}
}
The intention of the protocol is to verify if the sourceChannel is approved. However, the code unintentionally checks the destinationChannel instead.
Recommended Mitigation Steps
It is advised that the protocol confirms whether the source channel is on the whitelist.
// check source channel is in the whitelist channels
var found bool
for _, s := range params.WhitelistedChannels {
if s == packet.SourceChannel {
found = true
}
}
Lines of code
https://github.com/code-423n4/2023-06-canto/blob/a4ff2fd2e67e77e36528fad99f9d88149a5e8532/Canto/x/onboarding/keeper/ibc_callbacks.go#L47
Vulnerability details
Impact
Unauthorized source channels have the potential to illicitly initiate the onboarding swap mechanism. This scenario not only poses a risk to the security of the Canto network, but it also raises questions about the integrity of asset transfers. In the event of such a violation, the seamless and secure swap and conversion of assets to Canto via IBC middleware could be compromised, potentially allowing for unwanted transactions.
Given the explicit design of the system to trigger these operations only through whitelisted channels, any activation through unauthorized channels undermines the fundamental architecture and security parameters of the system. Therefore, the potential for unauthorized source channels to instigate the onboarding swap is a significant concern that necessitates immediate attention and rectification.
Proof of Concept
According to the specification:
When assets are transferred to the Canto network via the Gravity Bridge, the IBC transfer naturally sets off a swap and conversion to Canto via the IBC middleware. These operations are activated only when the transfer is made through an approved channel.
Also:
WhitelistedChannels: These are channels authorized for automatic swap and conversion. If the channel isn't on this list, automatic swap and conversion won't take place. The default setting is ["channel-0"], a channel for Gravity Bridge.
The team created a video walk-through to review the system architecture:
https://www.loom.com/share/632db169981740b2b149411c9249def5?sid=75e7de98-e5ab-4e17-a67d-dfe642f15b78
At the 2:59 mark, it is highlighted that the code verifies the source channel.
This is also confirmed in the code comment:
code
The intention of the protocol is to verify if the sourceChannel is approved. However, the code unintentionally checks the destinationChannel instead.
Recommended Mitigation Steps
It is advised that the protocol confirms whether the source channel is on the whitelist.
Assessed type
Access Control