CCA Smart Contract Auditing 3 — Questions and Answers
Question 1: What vulnerability is introduced when a Solidity contract performs arithmetic without overflow/underflow checks in versions prior to 0.8.0?
- Timestamp dependence
- Integer overflow/underflow (Correct answer)
- Unchecked external calls
- Delegatecall injection
Correct answer: Integer overflow/underflow
Prior to Solidity 0.8.0, arithmetic operations would silently wrap around on overflow/underflow, potentially allowing attackers to manipulate balances or counters.
Question 2: An auditor discovers a contract that relies on `block.timestamp` for a time-locked withdrawal. What is the main risk?
- Miners can manipulate timestamps by a small margin to affect condition checks (Correct answer)
- Block timestamps are not available in view functions
- Timestamps reset after each block
- Timestamp precision is insufficient for financial logic
Correct answer: Miners can manipulate timestamps by a small margin to affect condition checks
Miners have limited ability to manipulate `block.timestamp` by roughly 15 seconds, which can be enough to influence time-sensitive conditions.
Question 3: What is the purpose of a 'fuzz testing' tool like Echidna in smart contract security?
- To statically analyze bytecode for known vulnerability patterns
- To generate random inputs and detect property violations automatically (Correct answer)
- To formally verify mathematical invariants
- To simulate mainnet state during testing
Correct answer: To generate random inputs and detect property violations automatically
Echidna is a fuzzer that generates random transaction sequences to find inputs that violate user-defined properties or invariants in smart contracts.
Question 4: Which attack type exploits the ordering of transactions in the mempool to profit from a victim's pending transaction?
- Reentrancy
- Flash loan attack
- Front-running (MEV) (Correct answer)
- Sybil attack
Correct answer: Front-running (MEV)
Front-running, a form of Miner/Maximal Extractable Value (MEV), allows bots to observe pending transactions and submit competing transactions with higher gas fees to execute first.
Question 5: A contract uses `delegatecall` to an untrusted address. What is the primary danger?
- The callee can read the caller's private variables
- The callee's code executes in the caller's storage context, allowing state manipulation (Correct answer)
- The callee can steal the caller's ETH balance directly
- Delegatecall disables access control modifiers
Correct answer: The callee's code executes in the caller's storage context, allowing state manipulation
With `delegatecall`, the called contract's code runs using the calling contract's storage and context, so a malicious callee can overwrite critical state variables.
Question 6: What does a 'pull payment' pattern protect against in smart contract design?
- Timestamp manipulation
- Reentrancy and failed-send denial of service by separating withdrawal logic from business logic (Correct answer)
- Integer overflow during payout calculations
- Oracle price manipulation
Correct answer: Reentrancy and failed-send denial of service by separating withdrawal logic from business logic
Pull payments require recipients to withdraw their funds themselves, preventing a malicious recipient from causing the entire payout function to fail and blocking other recipients.
Question 7: During an audit, you find that a contract's constructor sets the owner but the contract is designed to be used as an implementation behind a proxy. What is the risk?
- The constructor logic runs twice
- Constructor code is not stored in bytecode, so the proxy never initializes the owner (Correct answer)
- The proxy cannot call the constructor directly
- Constructor arguments are publicly visible on-chain
Correct answer: Constructor code is not stored in bytecode, so the proxy never initializes the owner
For proxy-based upgradeable contracts, constructors do not run in the proxy's context; an `initialize` function must be used instead to set up state correctly.
What vulnerability is introduced when a Solidity contract performs arithmetic without overflow/underflow checks in versions prior to 0.8.0?