What is Cairo ?
In 2021, StarkWare introduced Cairo, a programming language designed for creating provable programs using zero-knowledge proofs. It serves as the smart contract language for Starknet, a layer-2 blockchain built on top of Ethereum.
This article explores some of the most common vulnerabilities in Cairo smart contracts. As Cairo has evolved a lot since it’s first version Cairo 0, this discussion focuses on vulnerabilities affecting smart contracts written in versions posterior to 1.0, with the current Cairo compiler version being 2.8.5 at the time of writing. The article examines some of the main classes of vulnerabilities, detailing how to detect them using tools developed by FuzzingLabs. Additionally, it provides insights into possible remediations.
By understanding these vulnerabilities and leveraging detection tools, developers can build more secure and robust smart contracts on StarkNet. Some of the vulnerabilities presented here are specific to Cairo, and some others are more generic smart contracts vulnerabilities.
An integer overflow occurs when an arithmetic operation produces a value outside the representable range for a given number of bits. This is common in languages using fixed-size integers, such as C or Java, where adding two large integers can exceed the maximum value storable in an int
.
In Cairo, the primary type is called felt
(corresponding to field element), represented by the keyword felt252
. It corresponds to an integer in the range 0 ≤ x < P
, where P is a 252-bit prime number defined as 2^251 + 17 * 2^192
. Overflows or underflows occur if values exceed P or fall below 0, but results are computed modulo P to bring them back within the range.
We can run the program using cairo-run
It successfully overflowed the maximum felt value and printed 0, because the result of (MAX_FELT_VALUE + 1) mod P is equal to 0.
We start by compiling the Cairo program into it’s Sierra intermediate representation:
Then we run the felt_overflow detector on the Sierra file:
To avoid overflow and underflow bugs with the felt type, prefer using integer types (i128, i16, i32, i64, i8, u128, u16, u256, u32, u64, u8, an usize), which include built-in overflow and underflow checks, instead of felts.
Interactions between Ethereum L1 contracts and Cairo contracts on StarkNet L2 can introduce various types of bugs. Here is a non-exhaustive list of examples:
The vulnerability arises from the mismatch in data types between Ethereum L1 and Starknet L2, particularly when transferring addresses or other uint256
values from L1 to L2. In Ethereum, addresses are uint160
, but during cross-layer messaging, they are often represented as uint256
. In Starknet, addresses are of the felt type, which has a smaller range (0 < x < P
, where P is 2^251 + 17 * 2^192
). This mismatch can lead to issues such as valid L1 addresses mapping to null or unexpected addresses on L2, potentially resulting in tokens being sent to unintended addresses.
To mitigate this, it is crucial to validate and verify parameters, especially user-supplied ones, when sending messages from L1 to L2. This ensures that the values fall within the acceptable range of the felt type in StarkNet, or to use the u256
type (or any other integer type similar to the one used in the L1 contract) in Cairo smart contracts when necessary, preventing unintended consequences.
To prevent fund loss, ensure all security checks are identical on both L1 and L2 sides. Asymmetrical validations can cause failed corresponding actions, leading to potential fund loss or service denial.
The following contract stores a secret in the secret storage field, if sensitive information is stored in the smart contract store, this is a vulnerability because the information will be accessible to anyone.
When writing a Cairo smart contract, remember that no data is private on the StarkNet blockchain. If your smart contract needs to store private data on-chain, consider encrypting the data off-chain before deploying it. Alternatively, you can replace plain-text values with hashes to preserve data privacy.
Just like in Solidity, reentrancy vulnerabilities are also possible in Cairo smart contracts deployed on StarkNet, with the same mechanisms.
The mitigations for this class of vulnerabilities are the same in Cairo. Just like in Solidity, OpenZeppelin has created a Reentrancy guard that can be used in Cairo smart contracts.
Here is an example of its usage in a function from the Argent wallet smart contract. The Reentrancy guard exposes two methods: start
and end
, which must be called at the beginning and end of the protected function:
It is also important to follow the Check-Effect-Interaction pattern, which is is a common design pattern used to prevent reentrancy attacks on Ethereum that can be copied in Cairo contracts.
The pattern involves following a specific order of operations in your functions:
Here is a snippet of code from the Carbonable Minter that follows this pattern :
In conclusion, this article has provided an in-depth look at some of the most common vulnerabilities that can occur when writing Cairo smart contracts. While it is imperative that smart contracts handling critical operations undergo thorough auditing, it is also important to note that many vulnerabilities can be automatically detected using various security tools. Tools such as the cairo-fuzzer can be employed for fuzzing, while static analysis tools like thoth and sierra-analyzer offer additional layers of security. By leveraging these tools, developers can significantly enhance the security and reliability of their Cairo smart contracts, ensuring a more robust and secure blockchain ecosystem.
Founded in 2021 and headquartered in Paris, FuzzingLabs is a cybersecurity startup specializing in vulnerability research, fuzzing, and blockchain security. We combine cutting-edge research with hands-on expertise to secure some of the most critical components in the blockchain ecosystem.
Contact us for an audit or long term partnership!