Subscribe to Officer's Blog
>4.5K subscribers
So today, we will examine the nature of the several bugs, their possible consequences, and the tactics that can be used to reduce similar risks in the future.
Keep in mind. Vigilance and expertise are essential for protecting the assets of the decentralized economy in the Web3 world, where every line of code has the potential to be a double-edged sword!
These unique assets, designed to adjust their supply based on market conditions, can introduce complexities that may lead to unforeseen vulnerabilities. While they offer intriguing advantages, such as automatic price stabilization, they also come with inherent risks, particularly when integrated into leveraged strategies. In other words, these tokens, endowed with the power to expand or contract their supply in response to arcane conditions, are both marvel and menace. In skilled hands, they sculpt elegant tokenomics; in the grasp of the careless, they sow discord.
Rebase tokens are unique assets that adjust their supply based on certain conditions, typically to maintain a target price or value. While they offer intriguing advantages, such as automatic price stabilisation, they also come with inherent risks, particularly when integrated into leveraged strategies.
So, rebase tokens have a history of causing trouble in DeFi systems.
Price Stability: By adjusting supply, rebase tokens can help maintain a stable price, making them attractive for users seeking to avoid volatility.
Automatic Adjustments: Users do not need to manually manage their holdings, as the protocol automatically adjusts balances based on market conditions.
Complexity: The mechanics of rebase tokens can be confusing for users, leading to misunderstandings about their actual holdings.
Rounding Errors: The process of adjusting balances can introduce rounding errors, which, while seemingly minor, can accumulate and lead to significant discrepancies over time.
Denial of Service (DoS) Vulnerabilities: The complexity of rebase mechanisms can make protocols susceptible to DoS attacks, where malicious actors exploit vulnerabilities to disrupt normal operations, potentially leading to financial losses for users.
Yet, in the world of finance, where precision is paramount, even the smallest discrepancy can have outsized consequences… Historical cases highlight the severity of these issues. For example, the KyberSwap hack, which resulted in a loss of approximately $53 million, was partly attributed to a rounding error in the smart contract’s logic. In the digital realm, such assaults seek to paralyze their targets, rendering contracts mute and motionless...
Rounding in smart contracts, especially in DeFi applications, is a vital aspect of secure development. Because Solidity lacks native floating-point arithmetic, developers must rely on integer division, which might result in exploitable rounding problems. These mistakes may lead to large financial disparities, money loss, or inaccurate awards.
In simple terms, rounding errors happen when a calculation in a smart contract doesn’t account for decimal places, leading to small inaccuracies. In Solidity, the language used for Ethereum smart contracts, these errors often occur because it only uses whole numbers (integers) and rounds down any fraction, like turning 5/2 into 2 instead of 2.5.
The relevance of pounding consists mostly when Precision is lost while splitting integers in Solidity because the decimal portion is lowered. With it, keep in mind that in intricate DeFi protocols, even slight rounding errors can add up to considerable pecuniary discrepancies. Rounding errors can be exploited, leading to attacks where hackers alter token balances or embezzle funds.
A rounding error is a mathematical miscalculation caused by altering a number to an integer or one with fewer decimals.
Developers can employ fixed-point arithmetic, which involves scaling values before dividing them, to manage rounding appropriately rather of depending only on integer division. This lowers rounding mistakes and enables more accurate computations. When computing ratios, it is also advised to conduct multiplication before division to reduce precision loss.
For example, instead of (a / b) * c, use (a * c) / b. Consider the rounding mode (e.g., banker’s rounding, rounding down, or rounding up) and how it may affect your computations.
To find any rounding problems and their effects on financial computations, test your smart contracts with different inputs and circumstances. Recognize and reduce the hazards of bidirectional rounding, which allows an attacker to manipulate rounding up or down using inputs. Developers can also use higher precision by working with larger units, like using wei (the smallest unit of Ether) instead of Ether directly.
They can also delay division until the end of calculations to keep accuracy, and ensure token distributions don’t leave “dust” by distributing sequentially. Tools like MythX can help catch these errors before they cause problems. To sum up, the root cause of rounding errors in Solidity is its integer-based arithmetic system:
Integer Division: When a division operation is performed, such as 5 / 2, the result is 2, not 2.5, because the fractional part (0.5) is discarded. This is known as truncation, which always rounds down.
Lack of Floating-Point Support: Unlike languages like JavaScript or Python, Solidity does not support floating-point data types. This forces developers to work with integers, which can lead to precision loss in calculations involving fractions.
EVM Constraints: The EVM, which executes smart contracts, operates on fixed-size integers, further limiting the ability to handle decimal precision without additional logic.
DoS attacks are a known menace in the world of Web3. A successful DoS attack may overload the system, making it impossible for authorized users to access their money and causing havoc on the platform.
A smart contract’s functionality can be compromised through Denial of Service attacks, where attackers exploit vulnerabilities to exhaust resources, rendering the contract unusable. This can prevent users from interacting with the contract as intended. Methods for denial of service attacks against smart contracts are rather straightforward and include, but are not restricted to, the following three:
Usually, the contract’s coding logic is inaccurate, which results in this kind of denial of service attack. The most typical instance is when the contract contains functionality that iterates across the incoming array or mapping. An attacker can use a lot of Gas by passing in a super-long map or array for loop traversal when there is no length limit on the incoming map or array. This will eventually cause the transaction’s Gas to overflow and make the smart contract unusable.
External call-based denial of service attack: This type of attack is brought on by the contract’s incorrect management of external calls. For instance, a smart contract has a knot that modifies the state of the contract in response to the execution of an external function, but it ignores the failure of the transaction. The smart contract will continue attempting to process the same erroneous data if an attacker intentionally causes a transaction failure. The smart contract is rendered ineffective either permanently or temporarily since the smart contract logic card cannot be used in this environment.
Denial of service attack based on operation management: For example, in smart contracts, the Owner account usually acts as the administrator, with a wide range of rights. The transfer function, for example, is susceptible to a non-subjective denial of service attack when the Owner role is compromised or the private key is lost. This might lead to the transfer function being enabled or suspended, among other things.
In the rapidly evolving landscape of Web3, security remains a paramount concern, especially in decentralized finance protocols. During the audit, the visibility and access permissions of every function methods must be reviewed and verified:
As a developer: Care should be taken while creating smart contracts to handle frequent errors, including executing potentially problematic external call logic asynchronously. Watch the gas usage when using Call to do traversals, loops, and external calls. Don’t give one role too much authority. In order to prevent permission loss due to private key leakage, roles with permissions should use multi-signature wallet management, and contract permissions should be handled with a sensible division of permissions.
As an auditor: Always check for logical mistakes that could impair the contract’s usability. Keep an eye out for the potential for a denial of service attack due to the excessive depth of virtual machine calls (1024 is the maximum depth). Pay close attention to whether the code’s logic uses a lot of gas.
When working with external contracts, pay special attention to compatibility issues. Verify that the return value from the external contract call matches the anticipated outcome. Additionally, implementing strict checks and balances for rebase tokens is crucial. This includes ensuring that the vault accurately tracks the total supply and adjusts user balances accordingly during each rebase event.
To ensure that the rights are in line with the design document descriptions during the audit, the project party’s design documents must be combined. To guarantee that administrative and operational errors are avoided once the contract is in effect, it is crucial to discuss process and method improvements with the project team if it is found that there are unnecessary authorizations or an unclear division of authority.
The game is afoot, and the stakes have never been higher. In this brave new world of code and cryptography, it is the collective efforts of hunters, auditors, and developers that will determine the fate of our digital future. Let us remain ever vigilant, for the villains of the blockchain are as cunning as they are relentless.
Officer's Blog
No comments yet