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

Unprotected bridgeIn and deployHolographableContract in HolographFactory are susceptible to replay attacks #111

Closed
code423n4 opened this issue Oct 22, 2022 · 1 comment
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working duplicate This issue or pull request already exists invalid This doesn't seem right

Comments

@code423n4
Copy link
Contributor

Lines of code

https://github.com/code-423n4/2022-10-holograph/blob/main/contracts/HolographFactory.sol#L160
https://github.com/code-423n4/2022-10-holograph/blob/main/contracts/HolographFactory.sol#L192

Vulnerability details

Impact

The creation of a holographable contract in a chain may be replayable in any other chain supported by the Holograph protocol.

The bridgeIn or deployHolographableContract can be called by anyone using the same parameters that were previously used to deploy a contract in a specific chain to deploy the same contract (that will render the same address) in any other chain.

Proof of Concept

Copy the arguments that were used to execute a transaction to bridgeIn or deployHolographableContract of the HolographFactory contract in a chain and recreate that same transaction in any other chain.

Recommended Mitigation Steps

I can think of two alternatives:

1- Protect the access to the bridgeIn function (and deployHolographableContract) so that it is only accessible by the bridge. Holographable owners would need to follow a bridging flow to deploy their contracts to other chains.
2- Include the chainId in the signature and verify it matches the current chainId that is executing the transaction. This way a payload/signature won't be replayable in another chain. Note that in this case the chainId can't be part of the hash that is used as the salt to create2, since it will create contracts with different addresses in different chains. The chainId should be included in the hash for signature verification but excluded in the hash for the create2 salt.

@code423n4 code423n4 added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working labels Oct 22, 2022
code423n4 added a commit that referenced this issue Oct 22, 2022
@gzeoneth
Copy link
Member

Duplicate of #178

@gzeoneth gzeoneth marked this as a duplicate of #178 Oct 31, 2022
@gzeoneth gzeoneth added the duplicate This issue or pull request already exists label Oct 31, 2022
@gzeoneth gzeoneth added the invalid This doesn't seem right label Nov 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working duplicate This issue or pull request already exists invalid This doesn't seem right
Projects
None yet
Development

No branches or pull requests

2 participants