John_Femi - Potential Hash Collision will cause overwrite of attestation

[sherlock-admin4]

John_Femi

Medium

Potential Hash Collision will cause overwrite of attestation

Summary

There is a possibility of hash collision if the service and account data in AttestationDetails matches a previous attestation that was done previously by another profile

Root Cause

in https://github.com/sherlock-audit/2024-10-ethos-network/blob/main/ethos/packages/contracts/contracts/EthosAttestation.sol#L428, we see that function getServiceAndAccountHash returns the hash for the hashStr used in createAttestation as seen in https://github.com/sherlock-audit/2024-10-ethos-network/blob/main/ethos/packages/contracts/contracts/EthosAttestation.sol#L184-L232

The hashStr is used to claimAttestation as seen in https://github.com/sherlock-audit/2024-10-ethos-network/blob/main/ethos/packages/contracts/contracts/EthosAttestation.sol#L269

It directly allows the profiled be overwritten, without a check to see if profileId is already previously claimed

// Set new profileId for attestation
    attestationByHash[attestationHash].profileId = profileId;
    attestationHashesByProfileId[profileId].push(attestationHash);
    // Update the index of the hash in the new profile
    hashIndexByProfileIdAndHash[profileId][attestationHash] =
      attestationHashesByProfileId[profileId].length -
      1;

    // Restore attestation if it was previously archived
    if (attestationByHash[attestationHash].archived) {
      attestationByHash[attestationHash].archived = false;
    }

Internal pre-conditions

1. AttestationDetails.service data must be same
2. AttestationDetails.account must be same

External pre-conditions

No response

Attack Path

No response

Impact

Overwriting of Previous Attestation done by a profile

PoC

No response

Mitigation

Check for a match in the hashStr before attempting to claim attestation in _claimAttestation