-
Notifications
You must be signed in to change notification settings - Fork 1
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
Fix/finding #2 Fix Calculating Salt #124
Fix/finding #2 Fix Calculating Salt #124
Conversation
…reshold parameters in createAccount and computeAccountAddress functions
… threshold parameters in createAccount and computeAccountAddress functions
…ture and improve readability
Fix/finding #2 Fix Calculating Salt
🚨 Report Summary
For more details view the full report in OpenZeppelin Code Inspector |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## remediations/cantina-spearbit #124 +/- ##
================================================================
Coverage ? 75.73%
================================================================
Files ? 13
Lines ? 643
Branches ? 148
================================================================
Hits ? 487
Misses ? 156
Partials ? 0
Continue to review full report in Codecov by Sentry.
|
mstore(0x40, add(ptr, calldataLength)) | ||
calldatacopy(ptr, 0x04, calldataLength) | ||
actualSalt := keccak256(ptr, calldataLength) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not quite sure why these two are not the same?
I believe this change was done only for gas optimisation from gaslite suggestion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you're effectively calculating keccak256(abi.encode(...params))
while his code is keccak256(abi.encodePacked(...params)
. Generally encodePack
-ing is cheaper but I can't say for sure in this case if re-encoding will be cheaper than copying and hashing pre-encoded data. Best to look at benchmarks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
check how arrays are abi encoded, there's an offset to the data (that can be chosen by the caller as the issue says) and you'd be encoding this offset too along with everything else.
audit finding #2 is linked wrong. it links to some issue |
calldatacopy(ptr, 0x04, calldataLength) | ||
actualSalt := keccak256(ptr, calldataLength) | ||
// Store initData at the free memory pointer | ||
calldatacopy(ptr, initData.offset, initData.length) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not consistent everywhere?
here it would be
bytes32 actualSalt = keccak256(abi.encodePacked(initData, salt))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's what it does but in assembly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean, why cant we just use this abi.encodePacked way everywhere then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's for gas mostly.
But where else it's not used?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
like in other factories we have changed and used like this
bytes32 actualSalt = keccak256(abi.encodePacked(eoaOwner, index, attesters, threshold));
go back to the issue please to also understand test case needs.
we are still hashing everything for salt event without any change, but in the event it would be emitted different value which won't help to reconstruct salt
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -42,14 +42,17 @@ contract NexusAccountFactory is Stakeable, INexusFactory { | |||
/// @param salt Unique salt for the Smart Account creation. | |||
/// @return The address of the newly created Nexus account. | |||
function createAccount(bytes calldata initData, bytes32 salt) external payable override returns (address payable) { | |||
// Compute the actual salt for deterministic deployment | |||
// Compute the actual salt as the hash of initData and salt using assembly |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
whats wrong with this comment
// Compute the actual salt for deterministic deployment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed it to reflect the changes, as we use hash of initData and Salt only (without sig func)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for deterministic deployment
Is nice and consistent..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -11,5 +11,7 @@ TestK1ValidatorFactory_Deployments | |||
│ └── it should return the expected address | |||
├── when creating an account with the same owner and index | |||
│ └── it should result in the same address | |||
└── when creating accounts with different indexes | |||
└── it should result in different addresses | |||
├── when creating accounts with different indexes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think tests should confirm that you're able to compute same account address using the initData and salt index emitted in the events.
or could be different params depending on the factory/method but you get the gist.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The written tests are valid in my opinion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
review i
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Aboudjem look over Chirag's comments
please check |
🤖 Slither Analysis Report 🔎Slither report
# Slither report
_This comment was automatically generated by the GitHub Actions workflow._
THIS CHECKLIST IS NOT COMPLETE. Use
constable-statesImpact: Optimization
|
0070740
into
remediations/cantina-spearbit
This PR addresses security audit finding #2 regarding non-deterministic salt computation in the
createAccount
function across several factory contracts. The following updates were made:K1ValidatorFactory:
NexusAccountFactory:
RegistryFactory:
isModuleAllowed
from public to private.Test Cases:
computeAccountAddress
function, ensuring the correctness of the salt computation fix.