Input arguments in the Bytes type may be invalid
Description
The Bytes type is defined in the third-party package alexandria_bytes:
/// Bytes is a cairo implementation of solidity Bytes in Big-endian.
/// It is a dynamic array of u128, where each element contains 16 bytes.
/// To save cost, the last element MUST be filled fully.
/// That means that every element should and MUST contain 16 bytes.
/// For example, if we have a Bytes with 33 bytes, we will have 3 elements.
/// Theoretically, the bytes look like this:
/// first element: [16 bytes]
/// second element: [16 bytes]
/// third element: [1 byte]
/// But in alexandria bytes, the last element should be padded with zero to make
/// it 16 bytes. So the alexandria bytes look like this:
/// first element: [16 bytes]
/// second element: [16 bytes]
/// third element: [1 byte] + [15 bytes zero padding]
/// Bytes is a dynamic array of u128, where each element contains 16 bytes.
/// - size: the number of bytes in the Bytes
/// - data: the data of the Bytes
#[derive(Drop, Clone, PartialEq, Serde)]
pub struct Bytes {
size: usize,
data: Array<u128>
}Note that it does not enforce the value of size to be consistent with the content of data. The size variable can contain a value that does not match with the content of the data variable if it is crafted by untrusted parties.
Since the behavior of the methods for the invalid Bytes value is undefined, it should be checked if it is given from the external sources like arguments. However, the functions dispatch and process do not validate the messages and metadata that are the Bytes type.
Impact
Invalid messages and metadata will be forwarded to the hook, ISM, recipient, and off-chain component. If these parties do not handle the invalid Bytes value consistently, a malicious user may exploit those inconsistent behaviors.
Recommendations
Consider sanitizing or validating the arguments in the Bytes type.
Remediation
This issue has been acknowledged by Pragma, and a fix was implemented in commit 2b38132e↗.