Arithmetic: overflow, and why the checks exist

Graduate · enrolled learners

This lesson opens with The SMT proxyOverflow, 2018.

What happened

The SMT token contract had a transfer function that took an amount and a fee and checked that the sender's balance was at least the amount plus the fee before moving the tokens. The arithmetic used fixed-size integers, which do not grow without limit; when a sum exceeds the maximum they can hold, they wrap around to a small number, an overflow. An attacker chose an enormous amount and a fee whose sum wrapped around to a tiny value, so the balance check, which compared the balance against that wrapped-around tiny sum, passed, even though the amount being transferred was astronomically large and the attacker did not hold it. The contract then moved the huge amount, creating tokens from nothing in effect, and exchanges suspended SMT trading in response. This vulnerability, and its siblings in other tokens the same year, needed no clever exploit of the network: they exploited that fixed-size integer math wraps silently, and that the contract trusted a sum it had not checked for overflow, on values an attacker fully controlled.

The decision point

On the EVM, integers are fixed-size and wrap around on overflow and underflow rather than growing or going negative, so arithmetic on attacker-controlled values can produce results that are mathematically impossible but that the code, doing unchecked math, treats as real, and a check built on such a result is defeated. The SMT proxyOverflow is the case: a balance check compared the balance against an amount plus a fee, but the attacker chose values whose sum wrapped around to a tiny number, so the check passed while the true amount was enormous, and the contract moved tokens the attacker never had. This extends the course's mental model of the EVM as a literal machine: it does exactly the arithmetic written, including wrapping when a value exceeds the fixed size, and it will not notice that the wrapped result is nonsense, because noticing is not something unchecked arithmetic does. The error is to reason about contract math as if integers were the unbounded numbers of ordinary intuition, when they are bounded and wrap, so a sum, a product, or a subtraction on hostile inputs can silently land somewhere impossible and pass a check that assumed it could not. So the discipline is to use arithmetic that is checked for overflow and underflow, current Solidity checks by default and older code used a safe-math library, and, beyond the language default, to reason explicitly about whether any calculation on attacker-controlled values could wrap, because a check standing on unchecked math is only as sound as the assumption that the math did not wrap. The SMT proxyOverflow is what wrapping arithmetic does to a trusting check: it lets an impossible number look valid just long enough to move tokens that were never there.

Orientation and Year One are open: anyone can read them without an account. From Year Two onward the lessons are for enrolled learners, because progress through the later years only means anything if it is tracked against a record.

It is free. We do not sell the list and there is nothing to buy at the end of it.