New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

Underhanded Solidity by Tynan Richards | Devcon Bogotá

DevconSat, Oct 7, 2023, 12:00 AM

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more. https://archive.devcon.org/archive/watch/6/underhanded-solidity/ A brief description of the exploit behind the winning submission to the Underhanded Solidity Contest 2022. Speaker(s): Tynan Richards Track: Security Keywords: Security,Exploit,Underhanded Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum Learn more about devcon: https://www.devcon.org/ Learn more about ethereum: https://ethereum.org/ Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022. Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

Transcript

foreign [Music] welcome to this lightning talk about the unspecified evaluation order in solidity or how our colleague Tina and Richard who unfortunately couldn't make it to Bogota won the underhanded solidity contest the goal of the underhanded solidity contest is to provide harmless or unsuspicious looking smart contracts with hidden bugs or pitfalls thereby exposing weird behavior and solidity in a fun way let's Jump Right In here's an excerpt from the solidity docs what it's basically saying is the evaluation the evaluation order of Expressions is not specified IF function f takes two arguments which are further function calls to functions G and H it's unclear in which order they are evaluated I don't function G is a related first or function H is evaluated first but we can never be sure which one obviously function f is evaluated last because it depends on the result of the other functions let's consider this example what let's say we call a function with an argument of two what's the correct result here is it four or five well it depends on the evaluation order and it's not really specified for the solidity compiler this is not unique to solidity insufficient specification to of expected Behavior can be found in all kinds of different programming languages a big headache for everyone involved does this matter in practice yes of course it does as it can lead to unexpected Behavior results by analyzing the code generator of the solidity compiler our collecting and found three cases of unusual evaluation orders which this talk is about yes most of the time evaluation order is as expected from Left of right but not always first two examples are the opcodes add mode and mule mode and here the evaluation order surprisingly is from right to left so if we evaluate F of 2 it first evaluates a incremented by one and only later evaluates the first argument which results in add mode with argument three two instead of 2 2 as you might have expected interestingly this is actually documented in the solidity however not where you expect in solidity there are currently two ways on how code can be compiled the default code generation and the new code generation via the UL IR pipeline in in the documentation describing the Euro pipeline it's actually documented that here the evaluation order will no longer be from right to left but also left right the most interesting one is the order of evaluation inside events this one is really special the parameters are evaluated in a bizarre order first the indexed parameters are evaluated from right to left then the remaining parameters are evaluated from left to right wow who knew that with solidity death has this in mind when coding no one right this can lead to really strange or unexpected Behavior and this is what tenen leveraged and used for his submission to the underhanded solidity contest 2022 he wrote a simple decentralized exchange where liquidity providers and the admin shared the collected fees in a legitimate tax the admin shouldn't be able to screw over the liquidity providers by changing the fees afterwards this is the heart of tenant submission looks legit right what's wrong here let's see so the admin calls functions change admin fees once he wants to update the fee it looks like function retire old admin fee is called first which execute claim fee this by and distributes the fees based on the old fee amount to the liquidity provider before calling set new admin fee which updates the admin fee to the new admin fee but remember what we just learned before indexed events are evaluated from right to left so actually set admin fees evaluated first so the fee is updated and only afterwards retire old admin fee distribute the liquidity fee to the liquidity liquidity providers based on the new fee really surprising so one important thing to mention here the solidity compiler as that has two ways to compile code the default way and the new way using the Yule IR pipeline in the Yule IR pipeline this is no longer true they are the function evaluation order is strictly from left to right however by default the solidity compiler uses the old code generation but this may change at any time in the future thanks a lot happy to take any question one minute left foreign

Automatic transcript — names and jargon may be misspelled.