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
Description
Whenever a message has received a quorum from guardians, relayers will call post_vaa to announce the message’s validity. The post_vaa function performs several validation checks one of which hashes the PostVAAData structure to ensure that it matches what the guardians signed. Each field of the structure is written into a vector of bytes and then hashed.
Improper usage of write_all where adjacent, dynamically-sized fields in a structure are hashed allows for collisions, breaking the assumption that each VAA corresponds to one message. If the fields emitter_address and payload in Figure 2.1 are moved in the future, this would be exacerbated.
let body = {
let mut v = Cursor::new(Vec::new());
v.write_u32::<BigEndian>(vaa.timestamp)?;
v.write_u32::<BigEndian>(vaa.nonce)?;
v.write_u16::<BigEndian>(vaa.emitter_chain)?;
v.write_all(&vaa.emitter_address)?;
v.write_u64::<BigEndian>(vaa.sequence)?;
v.write_u8(vaa.consistency_level)?;
v.write_all(&vaa.payload)?;
v.into_inner()
};
// Hash this body, which is expected to be the same as the hash currently stored in
the
// signature account, binding that set of signatures to this VAA.
let body_hash: [u8; 32] = {
let mut h = sha3::Keccak256::default();
h.write(body.as_slice())
.map_err(|_| ProgramError::InvalidArgument)?;
h.finalize().into()
};
Exploit Scenario
An attacker generates VAA data that is invalid but results in the same hash as one which has received signatures from a quorum of guardians . Then, the attacker submits the VAA data to a third-party program that uses the core messaging protocol. Since the program assumes only one valid structure exists for each VAA hash, it permits an invalid input, executing actions based on falsified data. The following is an example of a hash collision:
Figure 2.2: an example hash collision
Short term, insert the length of dynamically sized fields into the vector prior to hashing the
vector of bytes. Doing so will help avoid the possibility of hash collisions.
Long term, review the cardinality assumptions of VAA’s and messages to ensure that undefined behavior is not present.
The text was updated successfully, but these errors were encountered:
Target: solana/bridge/program/src/api/post_vaa.rs#L219-L238
Severity: Low
Description
Whenever a message has received a quorum from guardians, relayers will call post_vaa to announce the message’s validity. The post_vaa function performs several validation checks one of which hashes the PostVAAData structure to ensure that it matches what the guardians signed. Each field of the structure is written into a vector of bytes and then hashed.
Improper usage of write_all where adjacent, dynamically-sized fields in a structure are hashed allows for collisions, breaking the assumption that each VAA corresponds to one message. If the fields emitter_address and payload in Figure 2.1 are moved in the future, this would be exacerbated.
Exploit Scenario
An attacker generates VAA data that is invalid but results in the same hash as one which has received signatures from a quorum of guardians . Then, the attacker submits the VAA data to a third-party program that uses the core messaging protocol. Since the program assumes only one valid structure exists for each VAA hash, it permits an invalid input, executing actions based on falsified data. The following is an example of a hash collision:
Figure 2.2: an example hash collision
Short term, insert the length of dynamically sized fields into the vector prior to hashing the
vector of bytes. Doing so will help avoid the possibility of hash collisions.
Long term, review the cardinality assumptions of VAA’s and messages to ensure that undefined behavior is not present.
The text was updated successfully, but these errors were encountered: