Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Summa.sol : Issue with submitProofOfAddressOwnership() #7

Open
zzzuhaibmohd opened this issue Feb 22, 2024 · 4 comments
Open

Summa.sol : Issue with submitProofOfAddressOwnership() #7

zzzuhaibmohd opened this issue Feb 22, 2024 · 4 comments

Comments

@zzzuhaibmohd
Copy link
Collaborator

Describe the bug

Issue#1: submitProofOfAddressOwnership() does not allow to resubmit AddressOwnershipProof twice

Currently the require check at Summa.sol#L120 allows the onlyOwner to add the AddressOwnershipProof associated with the cexAddress only once.

But imagine a scenario, wherein wrong signature or message was submitted during the first iteration, it that case, there is no way to update these values in the future.


Issue#2: proofIndex generation does no take into account the name of the chain

The root cause of the issue can be slightly linked to the first issue, The hash calculation at Summa.sol#L117 does not take into consideration the chain as the input during calculation. While this might not look an issue for EVM chains. But when considering a multi chain architecture, using at least two input for generating the hash is a good practice. Currently thinking of a practical impact due to this.

To Reproduce
Yet to update PoC

Expected behavior
Issue#1: submitProofOfAddressOwnership() does not allow to resubmit AddressOwnershipProof twice

I my opinion , since the submitProofOfAddressOwnership() is permissioned(can only be called by onlyOwner), updating the message and signature should be allowed.


Issue#2: proofIndex generation does no take into account the name of the chain

Make the following changes in the addressHash generation to generate a more unique hash

-- bytes32 addressHash = keccak256(
--     abi.encodePacked(_addressOwnershipProofs[i].cexAddress)
-- );
++
++ bytes32 addressHash = keccak256(
++     abi.encodePacked(_addressOwnershipProofs[i].cexAddress, _addressOwnershipProofs[i].chain)
++ );

Additional context
Add any other context about the problem here.

@flyingnobita
Copy link
Collaborator

flyingnobita commented Feb 23, 2024

Issue#2: proofIndex generation does no take into account the name of the chain

To expand on the points given, it is not uncommon to have the same address on multiple chains (e.g. Ethereum Mainnet and a EVM derived change). Wouldn't using the address only for the hash will result in address of these chains to have the same hash, albeit they're separate wallets? Could this potentially leads to an address of 1 chain to be verified, while the same address on another chain to not needing verification?

@sebastiantf
Copy link
Collaborator

Agree that it is kinda confusing in the current implementation what is considered unique: (cexAddress) or (cexAddress, chain). Ideally it should be the latter to avoid confusion, be verbose and avoid the issues posted above

@0xalizk
Copy link
Member

0xalizk commented May 30, 2024

As a general note: I think Summa should incorporate domain separation

@alxkzmn
Copy link
Contributor

alxkzmn commented Jun 27, 2024

This is a valid concern when dealing with different blockchain architectures, not chains. Imagine a situation when one exchange claims the ownership of hash("0xabcd...123", "137") on Polygon, and the other of the same address hash("0xabcd...123", "1") but on mainnet :) This can be addressed either by convention offchain (e.g., all chains with the same architecture must have the same "chain ID" in context of Summa, like "EVM"), or enforcing the chain list in the smart contract.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants