This repository is designed to maintain a record of unique and fundamental vulnerabilities I discover during my smart contract audits. All the issues documented here have been reproduced using Foundry.
Inspired from SunSec(https://twitter.com/1nf0s3cpt)
Summary
The developers typically make assumptions, such as assuming that all ERC20 tokens have 18 decimal places. They then hardcode this assumed value into the contract. However, issues arise when ERC20 tokens with different decimal places interact with the contract. It's at this point that they realize the mistake they've made.
Test
forge test --match-contract IssueOneTest -vv
Summary
When implementing payable functions, the developer must monitor the amount of Ether sent to them via msg.value. If this amount exceeds the required value, it's crucial for the developer to initiate a refund back to the user. Failing to execute this step accurately could essentially be viewed as taking funds from the user without rightful cause.
Test
forge test --match-contract IssueTwoTest -vv
Summary
The issue highlights the potential vulnerabilities arising from unchecked user inputs in smart contracts. It demonstrates how failure to validate inputs can lead to malicious users evading fees. Smart contract developers are urged to assess input requirements and conduct thorough testing of input parameters controlled by users.
Test
forge test --match-contract IssueThreeTest -vv
Summary
Writing custom code for functions or logic that's already available is not considered good practice. Furthermore, if there are no unit tests in place, it's a recipe for disaster.
Test
forge test --match-contract IssueFourTest -vv
Summary
A regular, non-upgradeable Ownable library will make the deployer the default owner in the constructor. Due to a requirement of the proxy-based upgradeability system, no constructors can be used in upgradeable contracts. Therefore, there will be no owner when the contract is deployed as a proxy contract.
Test
forge test --match-contract IssueFiveTest -vv
Summary
Declaring an address as immutable in a smart contract can lead to issues, especially when the address serves vital functions like fee collection. The presence of blacklisting capabilities in tokens or private key compromise can disrupt protocol operations, making it essential for developers and auditors to assess these scenarios carefully.
Test
forge test --match-contract IssueSixTest -vv
Summary
When transfering native token balances (For Example: ETH), ensure proper tracking for each user. In EVM-compatible chains, native tokens can be forcefully sent to the contract via selfdestruct. If not handled promptly, this situation may result in contract malfunction, causing a Denial of Service (DoS) in our example.
Test
forge test --match-contract IssueSevenTest -vv
Summary
The issue revolves around the misconception that ReentrancyGuard alone is sufficient for preventing reentrancy vulnerabilities in smart contracts. It's evident that developers often overlook the importance of following the Checks-Effects-Interactions pattern, leading to potential exploits. In a specific example with a token bridge protocol, this flaw allows an attacker to manipulate the withdrawal process, exploiting a missed adherence to the CEI pattern and resulting in cross-function re-entrancy.
Test
forge test --match-contract IssueEightTest -vv
Summary
Smart contracts employ the pausable pattern to facilitate emergency halts, enabling developers to pause contracts during migrations, upgrades, or potential security threats. However, potential issues arise when different contracts inconsistently implement the pausable pattern, impacting users during emergencies, emphasizing the need for a unified pausing mechanism across multiple contracts to maintain consistency and prevent disruptions in critical scenarios.
Test
forge test --match-contract IssueNineTest -vv
Summary If there are functions that can be called by users and accept input parameters, it is always a good practice to validate these inputs for length, size, data type, etc. Skipping to do so can result in unexpected behavior. One such impact in this case was be users losing their deposited funds.
Test
forge test --match-contract IssueTenTest -vv
Summary Besides approaching problems from a developer/auditor mindset, it's essential to occasionally analyze and consider things from a user perspective. In essence, the assumption underlying the issues is: what if the user doesn't take a certain action, such as token migration?
Summary A Denial of Service attack vector that can affect honest users by hiding within a popular EIP designed to improve user experience. This highlights the importance of thinking outside the box during contract audits and having a comprehensive understanding of blockchain works.
Test
forge test --match-contract IssueTwelveTest -vv