Secure Mobility
Author: Aptos Labs and OtterSec
Aptos Network uses the Move smart contract language as its underlying programming model. While Move is designed for a secure smart contract ecosystem, improper implementation of Move itself can jeopardize these properties. At Aptos Labs, we are committed to making Move as secure as possible in collaboration with the community.
We are all investing in tools for writing correct smart contracts (such as Move Prover, primarily developed by Aptos) and the correctness of core runtime components like the Move virtual machine. In this article, we describe how we work with our partners to achieve the latter through audits, bug bounties, fuzz testing, and security enhancements of the underlying implementation.
What Are We Protecting?
The security of Move is based on several fundamental properties. These properties are defined according to the bytecode used by the Move execution engine and are independent of the source language:
- Type safety: Every value has a unique and unforgeable type. For example, it is impossible to take a value of type "address" and convert it into a security-related token of type "signer."
- Modular encapsulation: Resources in storage can only be manipulated by code within the module that declares those resources. Only functions with matching visibility can be called across modules.
- Ownership and lifecycle: Move's capability system enforces that values cannot be copied, deleted, stored, or used as keys unless the corresponding capability is declared for the value type.
- Reference safety: References do not outlive the values they point to. Mutable references are exclusive, making it impossible to use aliases.
The traditional architecture of the Move virtual machine delegates the verification of the above properties to a (bytecode) verifier, as shown in the diagram below:
The questions we are interested in are: Is the bytecode verifier complete, and does it guarantee that every program satisfies all of the above properties? This is important because violating any of the above properties could lead to asset loss. Does a given Move bytecode program cause the execution engine to crash? Because in a replicated state machine, all nodes execute the same program, this could be used to halt the network. Does a given program cause the execution engine to exhaust resources (memory or time)? This could be used for DoS attacks, slowing down or pausing the network.
How Do We Do It?
The core of developing bug-free code is the combination of strict software engineering practices with the right tools. At Aptos, we follow rigorous mandatory code reviews and continuous testing and integration processes, along with best practices from the Rust ecosystem. In addition to these traditional aspects, we also take the following measures to ensure that Move's security meets its design requirements.
Audits and Consulting
One of the most respected measures of confidence in blockchain networks is auditing. At Aptos Labs, we have contracted with Certik (report) and Halborn to audit the Move virtual machine. Several critical issues were discovered, one of which fell into the category of type safety.
In addition to external audits, Aptos Labs has also led and organized community audit efforts focusing on the bytecode verifier. Engineers from Mysten Labs, Starcoin, and auditing firms like MoveBit and OtterSec collaborated with Aptos engineers to complete this work, contributing approximately 6 person-weeks of audit time. This spreadsheet captures the results, referencing dozens of documents created during this audit. This audit work identified and resolved multiple issues before Aptos went live on the mainnet.
Last but not least, we have a close collaboration with OtterSec. The OtterSec team performed manual code reviews and developed fuzz testing techniques for various targets, identifying multiple critical issues in the Move VM and Aptos framework code. They also led efforts to add redundant defense logic to the Move VM (see below), influencing our ongoing design work to mitigate further vulnerabilities that could lead to financial loss.
Bug Bounty
Aptos Labs runs a bug bounty program. For severe bugs that could lead to asset loss, bounties of up to $1,000,000 are offered. Similarly, crash bugs can earn rewards of up to $100,000.
Through the bounty program, we work closely with a group of talented security researchers to find and fix vulnerabilities. Some of these bugs fall into the severe category, while others were discovered through the use of fuzzers.
Aptos Labs has fulfilled its commitment to the bug bounty program and has paid out substantial bounties. Furthermore, Aptos Labs continues to leverage the expertise of white-hat experts encountered through the bounty program and intends to continue collaborating with this community.
Fuzz Testing
The bounty program has prompted us to invest in fuzz testing at Aptos Labs. The Move VM code has been modified to implement "Arbitrary" Rust fuzz testing features at relevant points, allowing for dynamic generation and verification of bytecode modules using "cargo fuzz." We have ongoing work in running these fuzz testing targets.
Redundancy
One way to implement additional security assurances is through redundancy. We have added a so-called paranoid mode to the Move VM, which enforces type safety and the other rules mentioned above during execution. While the bytecode verifier checks these properties when the code enters the system, the paranoid mode revalidates the same checks during bytecode execution. The paranoid mode has been widely discussed within the Move community, with Aptos engineers leading the design. For more information, see this PR (final version) and this PR (intermediate version). What’s next?
At Aptos Labs, we are committed to making Move as secure as possible and have invested heavily in this area. Here, we have described our ongoing efforts with our partners around audits, bug bounties, fuzz testing, and enhancements. Looking ahead, we plan to continue investing in this field. We will continue to offer the bug bounty program, collaborate with reputable security auditors, and drive the development of security enhancement tools, such as fuzz testing techniques.