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
I would like to suggest a security enhancement for the _propose function. Currently, the _proposalId is not included in the root_merklehash. This might leave room for potential replay attacks.
To mitigate this risk, I propose that the _proposalId be included in the root_merklehash. This change would ensure that each proposal is uniquely identified in the root_merklehash, thus providing additional security against replay attacks.
Why does adding proposal id to merkle root can prevent replay attacks?
Under the current code, consider the following scenario:
calling contract perpareActionA(PA) creates a proposal P, params PA, merkle root MerkleRoot(PA)
Members vote for P, P accepted.
Call ActionA(P, PA) to execute the action
Under normal logic, ActionA's contract code should call setProposalExecuted(P), which sets P to Executed state.
When being replay attacked, someone call ActionA(P, PA) again, the operation will be rejected because the state of P is already Executed.
If ActionA does not call setProposalExecuted, replay attack ActionA(P, PA) will work
The situation does not change if the ID is added to the calculation of the merkle root:
Contract interface perpareActionA(PA) creates a proposal P,parameterized by PA, merkle root is MerkleRoot(PA+P)
At this point, if the logic is normal, replay attack ActionA(P, PA) still won't work
If setProposalExecuted is not called, then replay attack ActionA(P, PA) will also work.
I would like to suggest a security enhancement for the _propose function. Currently, the _proposalId is not included in the root_merklehash. This might leave room for potential replay attacks.
To mitigate this risk, I propose that the _proposalId be included in the root_merklehash. This change would ensure that each proposal is uniquely identified in the root_merklehash, thus providing additional security against replay attacks.
Thank you for considering this proposal. I believe this enhancement would significantly improve the security of the system.
The text was updated successfully, but these errors were encountered: