Article author:
0xGuard
0xGuard
Solana. Top Vulnerabilities
Currently, the Solana blockchain is very popular. The reason for this popularity is the very low transaction fees. More and more popular projects are being launched on the Solana blockchain, so now it is absolutely necessary to be aware of all the key vulnerabilities of Solana.
Integer overflow/underflow
The size of the input data either does not match the set limits for integer variables, or exceeds them.
This problem is considered to be one of the most common, and it is still relevant in the Solana blockchain.
An integer overflow occurs when a value greater than the maximum supported is attempted to be stored. This problem is not critical in itself, but can lead to more serious problems, just like integer underflow.
An integer overflow occurs when a value greater than the maximum supported is attempted to be stored. This problem is not critical in itself, but can lead to more serious problems, just like integer underflow.
Memory safety in Rust
An issue of invalid memory access
There is no access to invalid memory in all possible executions of the program. This conception is called memory safety.
There are violations that can cause programs to crash due to disruptions of intended behavior.
Moz://a Hacks article listed these violations:
There are violations that can cause programs to crash due to disruptions of intended behavior.
Moz://a Hacks article listed these violations:
- use after free
- null pointer dereference
- using uninitialized memory
- double free
- buffer overflow
Correct execution of authorization
Lack of ownership and signing the transaction with the corresponding account checks.
There are several check requirements.
One of the most important requirements in the Solana blockchain is the check of incoming data. It is necessary to check the correctness of the called contract and the type of contracts passed to the function. Another necessary check is checking the ownership of the accounts, and signing the transaction with the corresponding account. These are just a few examples. A good example of the lack of such checks is the WormHole exploit.
One of the most important requirements in the Solana blockchain is the check of incoming data. It is necessary to check the correctness of the called contract and the type of contracts passed to the function. Another necessary check is checking the ownership of the accounts, and signing the transaction with the corresponding account. These are just a few examples. A good example of the lack of such checks is the WormHole exploit.
Depth of cross-contract call
The depth of cross-contract invocations is limited to 4.
There are several check requirements.
One of the most important requirements in the Solana blockchain is the check of incoming data. It is necessary to check the correctness of the called contract and the type of contracts passed to the function. Another necessary check is checking the ownership of the accounts, and signing the transaction with the corresponding account. These are just a few examples. A good example of the lack of such checks is the WormHole exploit.
One of the most important requirements in the Solana blockchain is the check of incoming data. It is necessary to check the correctness of the called contract and the type of contracts passed to the function. Another necessary check is checking the ownership of the accounts, and signing the transaction with the corresponding account. These are just a few examples. A good example of the lack of such checks is the WormHole exploit.
Reentrancy attacks
Reentrancy attacks are possible.
Calling a program from an intermediate state by another program can lead to various consequences, since this program can be called back. In this case, the re-entry is limited by a simple self-recursion and a limited depth. Direct recursion gives the program full control over the state. Repeat attacks are not applicable to Solana, due to the limitations described above.
Errors in logic and arithmetic
Errors in the logic of the smart contract, leading to violations of functionality.
Due to the inattention of the developers, sometimes errors occur when writing contracts. This can lead to exploits due to loopholes. Moreover, even a simple typo can lead to unforeseen consequences. Arithmetic errors, inaccuracies, etc. are also common and most often the result of inattention, so it is always necessary to carefully check every line of code.
Computational units limit
Computational units limit of 48m CUs cannot be exceeded.
For transactions in the Solana blockchain, you need to pay computational units (CU), which is an analogue of gas in Ethereum-compatible chains. The current limit on computational units is 48 million, this limit cannot be exceeded.
Dependencies with vulnerabilities
Insufficient attention to checking dependencies.
The problem of using dependencies with vulnerabilities is very common, despite the fact that it is easy to fix. Dependencies may contain various vulnerabilities, or simply be outdated, so it is always necessary to take the time to check them.
Checking and studying the main vulnerabilities of the Solana blockchain are key factors in conducting an audit or project study.
CYSTACK
DeFi Security: Situation and Solution — Examples of DeFi Attacks Included
When you land on this page, you might have already heard of or even been using Decentralized finance (DeFi) to keep your money. However, you may be concerned to know that this technology is also appealing to cyber criminals attempting to steal your assets. It was reported that 97% of cryptocurrency stolen in 2022's first quarter was from DeFi protocols.
HASHEX
A Developer’s Guide: A Framework setup
Developers often ask how to correctly, efficiently, and securely set up a framework for developing smart contracts. This guide aims to help new developers do it quickly and conveniently.