CBSE Smart Contract Vulnerabilities 2 — Questions and Answers
Question 1: Which vulnerability allows an attacker to repeatedly call a withdrawal function before the balance is updated, draining contract funds?
- Integer overflow
- Reentrancy (Correct answer)
- Front-running
- Denial of service
Correct answer: Reentrancy
Reentrancy allows an attacker to re-enter a function before the first execution completes, exploiting the fact that the state update happens after the external call.
Question 2: In Solidity, which pattern best mitigates reentrancy attacks by updating state before making external calls?
- Oracle pattern
- Checks-Effects-Interactions pattern (Correct answer)
- Pull-over-push pattern
- Factory pattern
Correct answer: Checks-Effects-Interactions pattern
The Checks-Effects-Interactions pattern mandates updating all state variables before interacting with external contracts, preventing reentrancy.
Question 3: A smart contract stores the block timestamp as a source of randomness for a lottery. What vulnerability does this introduce?
- Integer underflow
- Access control flaw
- Miner manipulation of block.timestamp (Correct answer)
- Cross-function reentrancy
Correct answer: Miner manipulation of block.timestamp
Miners can adjust block.timestamp within a ~15-second window, allowing them to influence outcomes that depend on it as a randomness source.
Question 4: What is a 'tx.origin' attack in Ethereum smart contracts?
- Using tx.origin instead of msg.sender for authorization, which can be exploited via phishing contracts (Correct answer)
- Sending transactions with a forged origin address
- Overflowing the call stack via recursive calls
- Manipulating the transaction fee to bypass checks
Correct answer: Using tx.origin instead of msg.sender for authorization, which can be exploited via phishing contracts
tx.origin returns the original external account that initiated the call chain, so a malicious intermediate contract can trick a victim into authorizing an action unintentionally.
Question 5: Which EVM feature limits the depth of nested calls, and what vulnerability arises when this limit is hit unexpectedly?
- Gas limit — causes out-of-gas revert
- Call stack depth limit (1024) — causes unexpected call failures (Correct answer)
- Memory limit — causes memory overflow
- Storage limit — causes data truncation
Correct answer: Call stack depth limit (1024) — causes unexpected call failures
The EVM enforces a maximum call stack depth of 1,024; an attacker can pre-fill the stack so a subsequent call in the victim contract fails silently if unchecked.
Question 6: A contract uses 'delegatecall' to load logic from a library. The library's storage layout differs from the calling contract's layout. What is the risk?
- Gas theft by the library
- Storage collision, leading to unintended state overwrites (Correct answer)
- Permanent locking of funds in the library
- Infinite loop causing denial of service
Correct answer: Storage collision, leading to unintended state overwrites
delegatecall executes the library code in the caller's storage context, so mismatched slot layouts cause the library to overwrite critical state variables.
Question 7: Which vulnerability occurs when a Solidity contract performs arithmetic that silently wraps around due to type constraints in versions below 0.8.0?
- Overflow/underflow (Correct answer)
- Reentrancy
- Short address attack
- Signature replay
Correct answer: Overflow/underflow
Prior to Solidity 0.8.0, integer arithmetic did not automatically revert on overflow or underflow; values would silently wrap, enabling exploits like minting unlimited tokens.
CBSE Smart Contract Vulnerabilities 2
Which vulnerability allows an attacker to repeatedly call a withdrawal function before the balance is updated, draining contract funds?