Summary of the Rhinestone Core Module Audit

The Linestone Core Module is a set of smart account modules to expand smart account functionality. The Core Module Bundle includes the following modules developed by Linestone:

• Auto-save: Automatically saves a portion of the received tokens to the vault.
• ColdStorageHook: Protect your accounts by switching to cold storage for your assets
• ColdStorageFlashloan: Unlock the utility of assets in cold storage with flash loans
• DeadmanSwitch: Protect your account by setting up Deadman Switch
• HookMultiPlexer: Use multiple hooks based on specific conditions
• MultiFactor: Protect your account more securely by multiplying different validators
• OwnableExecutor: Control your account from another account.
• OwnableValidator: Own the account using an EOA or EOA set
• RegistryHook: Install only security modules using Rhinestone Registry
• ScheduledOrders: Automate swaps on a scheduled basis.
• ScheduledTransfers: Automatically transfer according to schedule
• SocialRecovery: Recover your account using a group of trusted friends

Linestone has contracted with Ackee Blockchain to conduct a security review of the Linestone Core module for a total of 21 days from April 29, 2024 to May 24, 2024.

methodology

We started our review using static analysis tools including Wake along with the Tools for Solidity VS Code extension. We then delved deeper into the logic of the contract. We used the Wake test framework for testing and fuzzing.

During our review, we paid special attention to the following:

• Check the logic of the example against the specification.
• Once you verify your assets, they cannot be locked or lost.
• Verification of ERC-3156 Flash Loan implementation,
• Ensures that ERC-4337 restrictions are followed.
• Detects possible reentrancy in your code.
• Verify that the system’s arithmetic is correct;
• Ensure that access control is neither too weak nor too strict.
• I’m looking for general issues like data validation.

range

An audit was performed on the commit. 013a123 The exact scope is the following files:

• Core modules excluding external dependencies
• SentinelList library(f3f84d6),
• CheckNSignatures library(53617ec).

result

Here we present our research findings.

Critical severity

No serious problems were found.

High severity

H1: Missing threshold check

H2: Remove from bad sig array removeSigHook

H3: OwnableExecutor Locked ether

H4: ERC-4337 Restricted Storage Access

H5: Nominee Access is restricted

H6: Externally increaseable borrower’s nonce

H7: ERC-3156 Flash Loan Implementation

Medium severity

M1: Missing sqrtPriceLimitX96 check

M2: Remove other addresses

M3: No module type conditions.

Low severity

L1: HookMultiPlexer No hook

L2: flashLoan Frontrunner

L3: Unsafe ERC-20 calls

L4: Missing initialized check in SentinelList.

L5: Missing executable element deletion

L6: Excluding list elements

Warning Severity

W1: MultiFactor Duplicate Verifier

W2: Missing clearTrustedForwarder call

W3: SchedulingBase Verification of number of executions

W4: 0 Check for missing address

W5: Missing array length validation.

W6: Check for missing values ​​in ERC-20 transfers

W7: TODO in module HookMultiPlexer

Informational severity

I1: AutoSavings Percentage precision

I2: Unused code

I3: Unused variables

I4: No prefix for inner function.

I5: Missing Events

I6: Typos and incorrect documentation

I7: Duplicate allocation SentinelList

I8: No feature limitations

I9: Refactoring suggestions HookMultiPlexer

conclusion

Our review yielded 32 findings ranging from informational to high severity.

The most serious high issues represent various issues in the codebase such as missing threshold check (H1), removing hooks from other lists (H2), locked Ether (H3), ERC-4337 restricted storage access (H4), and updates. waitPeriod Nominee (H5), externally incrementable borrower nonce (H6) and many violations of ERC-3156 flash loan implementation (H7). There are major issues in the codebase, so we recommend not deploying and using the contract until all serious issues are fixed. The code is mostly well documented, but the code quality is not as polished as the reference examples.

Ackee Blockchain recommends Rhinestone as follows:

• Add threshold protection when removing a validator/owner.
• Make sure that your contracts do not lock up your assets.
• Prevents interaction with limited storage slots as per ERC-4337 rules.
• fix lastAccess Reset candidate timestamp DeadmanSwitch contract,
• Fix whitelist bypass and nonce increase ColdStorageFlashloan contract,
• Strictly compliant with the ERC-3156 specification.
• Add a check to prevent slipping ScheduledOrders contract,
• fix SentinelList.pop Function parameter order ColdStorageFlashLoan.removeAddress ,
• Modify module type conditions ColdStorageHook function,
• Addresses all other reported issues.
• We perform full internal code reviews to ensure better code quality.
• Complete the missing documents.

Ackee Blockchain’s full Rhinestone Audit Report, which includes a more detailed explanation of all findings and recommendations, can be found here.

We are very happy to have appreciated Rhinestone and look forward to working with you again in the future.