Summary of the security audits for Aligned's Proof Verification Layer
Introduction
Recently, we launched Aligned mainnet beta, allowing developers and users to leverage the advantages of our proof verification layer. It's been less than a year since we proposed Aligned to deal with some of the leading problems for ZK adoption: high verification costs, low throughput, high latency, and constraints in the choice of proof systems. Since beginning work in February, we have been through:
- Cosmos testnet
- Testnet 1
- Testnet 2
- Security audits
- Improving telemetry
Our testnets have shown that Aligned can work with different proof systems, being able to handle large batches of proofs and reach thousands of proofs per second while providing significant cost reduction. The latest testnet worked with 42 operators, verifying over 340,000 batches and over 34,000,000 proofs. During the process, we received feedback from operators, users, and developers to improve the design of Aligned and the documentation. We also organized a hackathon to develop applications that can leverage Aligned's capabilities.
This post will provide an overview of the security audit process we went through and how we addressed the findings and suggestions of the auditing teams. We will continue testing, improving, auditing, and having bug bounties on Aligned to ensure that it works as intended, offering cheap and fast verification with a simple user experience.
Audits
We were audited by the following teams (in alphabetical order):
Among the priorities of the audits were:
- Check the correctness of the implementation, making sure it is consistent with the intended functionality and without unintended edge cases.
- Ensure that requests are passed correctly to the network core.
- Identify known vulnerabilities particular to smart contract systems.
- Assess the integration with EigenLayer AVS.
- Analyze race conditions.
- Perform static code analysis and fuzzing.
The commit used for the audits is 325aef8c3f54ec596b4733956a8ac487d5535fc3.
We are grateful to all these amazing teams for their commitment, work, findings, and suggestions, which have helped us improve Aligned and ensure everything is in place.
Security findings and our fixes
The following is a list of issues and the pull requests addressing them (for a more thorough description, see the links provided for each item).
The list of critical or high-level vulnerabilities found by the teams is:
- Multiple out-of-bounds (OOB) vulnerabilities in the verify function.
- Operators are vulnerable to out-of-memory (OOM) when fetching a batch, leading to a denial-of-service (DoS) attack.
- Bypass operator length check when fetching a batch.
- Public Visibility on checkMerkleRootAndVerifySignatures allows for DoS attacks and user fund loss.
- BatcherPaymentService - onlyBatcher Restriction, batchMerkleRoot Verification, pausable, and feePerProof can be bypassed entirely by calling AlignedLayerServiceManager directly.
- Unsafe pointer casting without length verification.
- BatcherPaymentService is vulnerable to DoS and grief via frontrunning.
- Aggregator fee can be MEV.
- A batch can be submitted without paying the batcher fee.
- An Aligned user can be front-run when creating a task leading to a user DoS.
- tx.gasprice allows a malicious user to steal all funds from the Batcher Balance.
- Attack on aggregator race condition leads to batch censoring.
- Batcher Balance may be insufficient.
- Use EIP-712 hashing to prevent cross chain replay.
- verify_merkle_tree_batch_FFI can panic.
- Amplified denial of wallet.
- OOM explorer when fetching batch.
List of PRs addressing the findings:
- Update FFI bindings to check buffers.
- Inconsistency between batcher and operator can lead to denial of service.
- Batcher does not perform sufficient input validation.
- Null pointer dereference in the Operator codebase can lead to denial of service.
- Missing Content-Security-Policy in router.ex.
- Fix out-of-memory error with gzip bomb and bypass length check.
- Use Open Zeppelin lib for signature verification instead of ecrecover.
- Frontrunning createNewTask leads to loss of funds.
- Public visibility on checkMerkleRootAndVerifySignatures() allows frontrunning and DOS attacking legitimate user signature submissions.
- Frontrunning createNewTask() on AlignedLayerServiceManager allows to DOS legitimate batch submissions.
- Unnecesary low-level call (address.call, service 105).
- After unlocking once, user remains unlocked.
- Non-atomic deployment of Batcher.
- Critical State operations lack event emitting.
- StorageLayout Contract should be declared abstract.
- SM initialize should call __ServiceManagerBase__init.
- Unused variable.
- Unused imports.
- Missing ecrecover validation.
- User-Batcher Payment Redesign.
- Provide an interface for AlignedLayerServiceManager.
- Specify contract instead of using address.
- AlignedServiceManager funds cannot be withdrawn.
- Aligned Service Manager is vulnerable to MEV.
- Batcher balance may be insufficient - limit aggregator spending.
- EIP-712 hashing to prevent cross chain replay.
- Usage of storage gaps in upgradeable contracts.
- Unnecessary panic in critical component.
- Outdated dependencies.
- It is not necessary to check err != nil when returning err.
- Functions that return a result should not panic.
- Usage of block count instead of block timestamp.
- BatcherPaymentService contract does not check that an address is not equal to address(0) during constructor or initialization.
- Inconsistent Serialization in the Marshal & Unmarshal Functions. Add Fuzzer for cbor serialization in Operator.
- No enforcement of strong passwords for keystores.
- The function fetch_batch_data_pointer in the explorer reads the entire response body without any limitations, which can lead to an OOM attack.
- BatcherPaymentService incomplete initialization.
- Batcher timeout to prevent simple DOS.
Bug Bounties
Once Aligned reaches mainnet, we intend to have a bug bounty program to continue improving and securing Aligned.
Summary
It's been less than a year since we proposed Aligned to solve the problems associated with proof verification in Ethereum. Since then, we have gone through three testnets and the security audits performed by four teams: Consensys, Fuzzing Labs, Least Authority, and Trail of Bits. Their findings and suggestions have helped improve not only the security and reliability of Aligned, but also the code quality. All critical and major points in the audits have been addressed, and we have improved the telemetry and reliability of Aligned. We will continue enhancing the performance of Aligned and its reliability and security, with top teams auditing it.