Trusting caller-supplied data and external code

Graduate · enrolled learners

This lesson opens with Superfluid, February 2022.

What happened

Superfluid is a protocol for streaming, real-time token transfers, built on composable agreements that pass around an encoded context, a ctx, describing who the real caller is as calls move through the system. The framework trusted that caller-supplied encoded context without fully validating it, so an attacker crafted a forged ctx that claimed to be other accounts and applications, and the protocol believed it. Acting as accounts it was not, the attacker drained about 8.7 million dollars; much of it was later returned. Nothing cryptographic was broken: the attacker did not forge a signature or steal a key, they simply handed the contract a piece of data that said 'I am someone else,' and the contract took the data at its word. The identity that governed who could do what was carried in caller-supplied bytes, and caller-supplied bytes are written by whoever is calling, including an attacker, so trusting them to describe the caller honestly was trusting the attacker to tell the truth.

The decision point

Any data a caller hands to a contract is written by the caller, so it is attacker-controlled and must be validated rather than trusted, and this is most dangerous when the data claims to describe who the caller is, because a contract that believes caller-supplied identity has handed the attacker the ability to be anyone. Superfluid is the case: identity flowed through the system in an encoded context supplied along with the call, the framework trusted that context without fully validating it, and an attacker forged a context claiming to be other accounts and drained about 8.7 million dollars, without breaking any cryptography, simply by lying in the data. The mental model from the prior lessons extends here: the machine runs the literal code, and the literal code trusted a claim it should have checked, so the contract's belief about who was calling was only as true as the caller chose to make it. The same applies to external code a contract calls into: its behavior is not under your control, so a contract that assumes a called contract will behave well is trusting code an attacker may have written or may control. So the discipline is to treat every input as hostile until validated, to never let caller-supplied data stand as proof of identity or authority when the code could instead verify it against something the caller cannot forge, and to treat external calls as calls into potentially hostile code, because the boundary of what you can trust ends at your own validated state, and Superfluid is what happens when a contract accepts the caller's word for who they are: the caller says they are someone else, and the contract lets them be.

Recorded loss

$8,700,000

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.