Solana
Top Solana Vulnerabilities
2022-05-20
Solana is a widely popular blockchain and attractively low transaction fees are certainly among the reasons developers choose it.
Among Solana-based dApps are some of the most popular and valued projects. This is why knowing Solana and its weaker points is now more necessary than ever.
Vulnerabilities to check
Correct implementation of authorization
The issue: missing ownership and signing checks
One of the crucially important necessities in Solana performing checks on the input data. Checking ownership of accounts as well as the fact that transactions are signed by an appropriate account. Another check that’s required is for the type of contracts passed to function and a check for the correct contract being called. That’s not all of them and the most prominent example of missing the aforementioned checks is WormHole exploit.
One of the crucially important necessities in Solana performing checks on the input data. Checking ownership of accounts as well as the fact that transactions are signed by an appropriate account. Another check that’s required is for the type of contracts passed to function and a check for the correct contract being called. That’s not all of them and the most prominent example of missing the aforementioned checks is WormHole exploit.
Integer overflow and underflow
The issue: Input size either doesn’t meet or exceeds the set integer variables boundaries.
Smart contract developers have been coming across this issue since the early days of Solidity, and it remains in Solana. It’s considered one of the most classic issues. Integer overflow occurs when you attempt to store a value that exceeds the highest supported value. While integer overflow itself isn’t critical, it is a gateway to more complicated issues. Same goes for integer underflow.
Smart contract developers have been coming across this issue since the early days of Solidity, and it remains in Solana. It’s considered one of the most classic issues. Integer overflow occurs when you attempt to store a value that exceeds the highest supported value. While integer overflow itself isn’t critical, it is a gateway to more complicated issues. Same goes for integer underflow.
Depth of cross-contract invocation
The issue: the depth of cross-contract calls in Solana is limited to 4.
When one smart contract has to invoke a method from another, a cross-contract call occurs. Thus, by interacting between different contracts, developers can create complicated processes. This way, a client can perform a transaction that modifies not one, but two accounts that are owned by separate programs within the same chain.
This feature allows invoking other programs directly, while the depth is limited to 4. Although according to Solana documentation, this may change in the future.
When one smart contract has to invoke a method from another, a cross-contract call occurs. Thus, by interacting between different contracts, developers can create complicated processes. This way, a client can perform a transaction that modifies not one, but two accounts that are owned by separate programs within the same chain.
This feature allows invoking other programs directly, while the depth is limited to 4. Although according to Solana documentation, this may change in the future.
Rust memory safety
The issue: Invalid memory access
The concept of memory safety implies that in any and all executions of the program, no access to invalid memory is provided.
According to this Moz://a Hacks article, the list of violations includes:
The concept of memory safety implies that in any and all executions of the program, no access to invalid memory is provided.
According to this Moz://a Hacks article, the list of violations includes:
- Use after free;
- Null pointer dereference;
- Using uninitialized memory;
- Double free;
- Buffer overflow
Invalid dependencies
The issue: Outdated dependencies, or using dependencies with vulnerabilities
While it’s relatively easy to manage dependencies in Rust, it’s important to check them anyway. Dependencies can be outdated or contain known and unknown vulnerabilities. This is a popular issue likely because it’s seemingly easy to fix.
While it’s relatively easy to manage dependencies in Rust, it’s important to check them anyway. Dependencies can be outdated or contain known and unknown vulnerabilities. This is a popular issue likely because it’s seemingly easy to fix.
Exceeding Computational units limit
The issue: Computational units are limited to 48M CUs
What’s commonly called gas in Ethereum-compatible chains is called computational units or CUs in Solana. Currently, the cap for CUs is 48M and it’s vital to not exceed this limit.
What’s commonly called gas in Ethereum-compatible chains is called computational units or CUs in Solana. Currently, the cap for CUs is 48M and it’s vital to not exceed this limit.
Logic Errors
The issue: Issues in the contract logic that affect its functionality
Logic errors often occur if the developer has made a mistake while writing the contract, and left a loophole that attackers can potentially use. It can be nearly anything from a simple typo to misunderstanding the specifications.
Logic errors often occur if the developer has made a mistake while writing the contract, and left a loophole that attackers can potentially use. It can be nearly anything from a simple typo to misunderstanding the specifications.
Errors in calculations
The issue: Precision errors, casting errors, etc
Arithmetic errors are also common and most often occur as a result of inadvertence. However, instead of relying on good intentions, it’s always better to make the necessary checks.
Arithmetic errors are also common and most often occur as a result of inadvertence. However, instead of relying on good intentions, it’s always better to make the necessary checks.
Reentrancy
The issue: possibility of reentrancy attacks
According to Solana Docs, reentrancy is limited to direct self-recursion, capped at a fixed depth.
A situation where a program invokes another from an intermediary state without knowing that it might be called back into. Full control of the state is given to the program by Direct recursion.
Because of these restrictions, typical for Solidity reentrancy attacks aren’t applicable to Solana.
Knowing and considering the main vulnerabilities that may occur in a Solana smart contract, certainly gives an advantage to developers as well as users reviewing smart contract audits. Which is why it’s always useful to have this article at hand while dealing with Solana contracts.
According to Solana Docs, reentrancy is limited to direct self-recursion, capped at a fixed depth.
A situation where a program invokes another from an intermediary state without knowing that it might be called back into. Full control of the state is given to the program by Direct recursion.
Because of these restrictions, typical for Solidity reentrancy attacks aren’t applicable to Solana.
Knowing and considering the main vulnerabilities that may occur in a Solana smart contract, certainly gives an advantage to developers as well as users reviewing smart contract audits. Which is why it’s always useful to have this article at hand while dealing with Solana contracts.