You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During the testing of memo format and its validation, mainly by using already written ibc integration tests, we were able to insert a very large string into the memo field of the packet data, specifically the string was inserted in the raw_message_data:
{
//... other ibc fields that we don't care about"data":{
"denom": "denom on counterparty chain (e.g. uatom)", // will be transformed to the local denom (ibc/...)"amount": "1000",
"sender": "addr on counterparty chain", // will be transformed"receiver": "contract addr or blank",
"memo": {
"wasm": {
"contract": "osmo1contractAddr",
"msg": {
"raw_message_fields": "raw_message_data",
}
}
}
}
}
The test was run with this newly changed memo, and as a result, a panic with the following trace occurred:
It is clear that panic was a result of gas usage handling, which is expected, but it seems that it would be more useful and more informative to set up input string validation and return a more exploratory error to inform the user why the transaction failed.
In addition to the case mentioned above, it is noticed that string length validation is rarely used across the module. It could be useful to prevent errors deeper in the execution and inform the user what exactly went wrong with the input.
After consulting with the Osmosis team and their recommendation to apply a limit to length of all the strings in the packet and performed analysis to check if there are any other vulnerable points, it seems that the proposed solution should be enough since all the strings that could be maliciously inserted in such a length to cause panic actually originate from packet.
The text was updated successfully, but these errors were encountered:
I think this is behaving as we want it for now. There are use cases where users may need longer memos, and it feels like we would need to keep updating those lengths if they are limited.
Involved artifacts
Description
During the testing of memo format and its validation, mainly by using already written ibc integration tests, we were able to insert a very large string into the memo field of the packet data, specifically the string was inserted in the raw_message_data:
The test was run with this newly changed memo, and as a result, a panic with the following trace occurred:
It is clear that panic was a result of gas usage handling, which is expected, but it seems that it would be more useful and more informative to set up input string validation and return a more exploratory error to inform the user why the transaction failed.
In addition to the case mentioned above, it is noticed that string length validation is rarely used across the module. It could be useful to prevent errors deeper in the execution and inform the user what exactly went wrong with the input.
After consulting with the Osmosis team and their recommendation to apply a limit to length of all the strings in the packet and performed analysis to check if there are any other vulnerable points, it seems that the proposed solution should be enough since all the strings that could be maliciously inserted in such a length to cause panic actually originate from packet.
The text was updated successfully, but these errors were encountered: