Panel: USCC – The Underhanded Solidity Coding Contest

[Music] so good afternoon earlier this year I started the first underhanded solidity coat contest and the goal was to write code that looked innocent on the surface but actually concealed a sinister purpose the reason that I started this was to encourage deeper thought about smart contract coding practices and and good code and to help highlight potentially issues with unobvious features and solidity and and smart contract programming so in an attempt to capture the sort of current zeitgeist the theme was token sales and participants were challenged to write a contract that was in some way involved with token sales and looked innocent but had some advantage for the person running the token sale and ideally the sinister purpose should be by ignored by an auditor or if it was discovered then easily excusable or explainable as an innocent mistake and so I have here the three winners of the contest this year we have Joelle who came in third Richard who came in second and Martin who came in first and so I'd like to start the our discussion about smart contract security by asking each of the panelists to describe their winning salute winning entry and what they think is a novel about it so would you like to start sure well my entry is a proposal for a Dutch auction crowd sale so in this model the sale starts with really high price per token that decreases continually as the as the patent as the time passes so buyers can enter the sale in whatever time the issue the price is fair the CEO ends or when either the the time finishes or they cut the door sorry or the capped is reached so the thing is I made use of a feature of solidity that is that anyone can forcibly send error to a contract without tricking code execution so in that scenario the co-owners could sneak in some header during the sale to inflate the token price making the touch the traction and earlier so if you couple that with for example a min table token that is a token that you only mint amount of token that was bought you can like really inflate the token price because you put money on the on the auction but you don't mint tokens so you're raising valuation of the token artificially irregardless of marketing interest and another retail is you can kind of use this as an as an influence it because if people are watching the sale and they see that it's it's reaching the cap really fast they might want you getting earlier than they would if in normal conditions so it's an kind of effective way to manipulate market in your favour using this this little feature right and Richard would you describe your submission okay testing there we go so very similar I actually didn't know about the suicide bug which allowed you to get money into a contract with a code execution but it basically uses the same idea which is there was a so the basic idea of the contract is you have a crowd sale and the the runner of the the runner yeah the issuer of the token gets one either the first week to ether the second week for the next week so on and so on the idea being that if they're not doing what you expect you can kind of yank your money back from them it comes down to using this stop balance and so again as long as the contract isn't executing as you expect this stop balance can never be more than the amount you received unlike the suicided method which again I don't know about but I have more clever solutions now if I was new of that the basically you compute the address the contract is going to live at before you deploy it send ether to it and now you deploy the contract at now the contract actually is breaking the invariant that this stop balance is strictly less than the amount it thinks it has great and finally Madame's so in my entry I I'm gonna start by describing the bug my entry is based on a bi encoding and how solidity handles a bi decoding in run time maybe everyone doesn't know that actual the EVM and the code in a contract doesn't really have a notion of methods that's an invention on top of the EVM so on the fly some bytecode determines what method is called and what the parameters are and this is encoded by a ABI and certain types of parameters such as dynamic dynamic length arrays have a length and that length is not enforced by the decoder so it's possible I noticed to specify a very very large length and make the this value overflow and that's what I kind of designed my entry around and it was a bit difficult because I had to make sure that during a loop I can't loop against the size but still use the size to somehow give a kick back to the attacker and in the end it became a kind of a round table where you can round table Dao like thing which you can pay for try to get a seat on this round table and submit multiple bits and thus get the dynamic arrays in there and what I think was pretty good about that entry is that this exploit is basically not possible to exploit using standard tools you need to generate your own ABI your little bytes of data in order to exploit this and I think it would be very difficult for solidity contract developer or auditor without deep insight into other VM functions to actually find the vulnerability so first of all in a question for any of the panelists would like to answer which is what should smart contract auditors be looking for in order to try and to take these sort of underhanded tricks I mean and I think in the case of our entries if you see this stop balance anywhere it should be I mean this means wrong but it's certainly a red flag that you're accessing data that may or may not be what you expect it to be to complement on these there are a few things that tip me off one example is random numbers because it's usually pretty hard to generate random numbers and it that kind of indicates that it's a point of failure external calls are also a kind of security edge because you know you're calling strong external contracts so it's the thing it's the kind of thing that I start looking after when I start looking at a contract yeah I would like to add to that that what you really kind of should be looking for one of the things is are these assumptions and they're mainly implicit assumptions that are made and it's easy to gloss over that and not notice it but really try to investigate where are the implicit assumptions here and in your cases are just the implicit assumption is that the balance is zero at the entry or at the exit and start to like make these assumptions explicit and then see can I violate this assumption in any way shape or form and just to add my own note do you some caution is required there unless if you made the assumption that the balance is zero and then you've coded in an assertion the balance is zero then now an attacker has a mechanism by which they can actually just disable your contracts by sending someone's to it exactly so so I I didn't mean that you should you know assert that thing necessarily but instead question is this the valid assumption that can be made or can this be exploited by an attacker so next question again for any of you is what sort of improvements would you like to see to tolling in two languages and and other infrastructure pieces in order to make it easier to take these issues and and help prevent them from happening in the first place so on the tooling front I was at the she's me at the breakout session earlier and saw some presentation about a Yenta and about sakura phi and for a long time I've had this feeling that there are these tools to with just analysis on bytecode and either detects vulnerabilities or provides some kind of analysis on the bytecode and they're on the kind of fringes but they're not right now in the in the tool set of most the app developers and that's what I think should be added so that as part of your development process you can get some aid by these tools which operates preferably on byte code which would also help to protect against failures and better within the solidity and in this step from source code to byte code all right so you'd say more maturity and the tools were already building and an easier integration yes in zero integration in the into the developer pipeline of these tools yeah anyone else I mean I would out yeah that's basically why I say like it's really important we have better testing tools as well like being able to run a huge suite of test cases against both expected behavior and unexpected behavior if you feed bad data in do you still get a result and now you've corrupted something or like I just think we need more and I think the tools are there I think it's just they're not easy to use it's not easy to make a test we can just run through them you you you see all these contracts they have about three test cases and it's testing if I send money to this not like this thing doesn't work yes passed and so three test cases this should not be sufficient to validate that this contract you're sending billions of dollars to is is working and yeah it's a and just in addition to that I would like to see some way to test in large scale because most projects when it tests some behavior they used like the minimum the viable number of players in the contract to test but if a contract work like with ten transactions will it work with ten thousand or a million and there's no H test that there is but there is no no one doing that right now so I would like to see some some work on that alright and if you each could give one piece of advice to somebody writing a smart contract on something to look out for or something to be careful about what would it be I would I would give a device that sometimes the code work has intended but they make mechanisms behind it or not so sometimes it's not about the codes about the way you design your contracts about how we interact people interact you don't consider that that might be a malicious player interacting with it that someone is like no bad behavior and it's kind of easy to oversee that and just like because it passes the test it works but you have to account for like bad people right now I again will just mimic the same thing I mean formal verification everyone thinks is this magic bullet but there's still a gun the game here you have to think about I mean we've heard about minor front-running this is a great example of the type of things that the code is doing exactly what you expected to do there's nothing being lied about about what's happening is just people who have weird connections to what's going to happen have too much say and can tweak what you expected to game theoretically or mechanism design wise work yes my top recommendations would be no the EVM in detail and keep it simple don't build like very large inheritance models because it just try to keep it simple and much easier to audit last one dropped out all right so I'd like to see are there questions from the audience for the panelists if you raise your hand and shout it out I'll repeat the questions who've Rankin here nobody has any questions about smart contract security okay hi I've seen like it many companies or individuals does like code auditing but there's no much standard if you want to say like if we're gonna have a code auditing standard or something what kind of stuff should be understand our list so effectively you're asking how would you recommend people go about auditing code is there is there best practice for that is that right yes best practices for auditors and audits so I'll say there's been some work in that direction I think mainly done by consensus they've put together a best practices guide but as I mean in general it's the field is not yet mature it's taken a lot of years to even get kind of like rough web application security guidelines going and still evolving and it's the same thing here new things get added as hacks happen so yeah there's I don't know it's it's going to continue to evolve there is one but it's not it's not all complete one other thing I agree we need something like that we also need some I would like the idea that auditing should be a fairly public type thing I've done many audits and often times I'll say like oh well your your can be exploited if this character who owns this address does this thing and often I hear there's like oh that's the lead developer he won't ever do that to us and that's not counting for him a being malicious him or her or them being hacked and their computers private key being stolen so I had to offer inhere in response to a completely valid audit well that won't happen and that's you're losing some of the value of blockchain so well we're talking about audits at a very high level would you describe how you go about an audit like how do you go from here's a big chunk of code to - here's a finished audit report I would say I mean usually to be fair most most audits I feel aren't actually large amounts of code like the Dow looked way larger than anything I've needed to audit before that was like a lot of code for what I was doing but even with one issue or thing that actually makes this describing this process a little bit easier is usually it's very modular usually there is a wack ton of contracts that are all inheriting for each other using each other so it makes it easy to kind of break it down and and yeah I usually just start at the top go through it and probably call you browse Wikipedia you hit like some good class you're like I don't wanna means and so you jump with that file and you go through that and it is then you start popping the stack and get up and you have to go over it a few times before yeah that's a good point the first thing you do is really understand what the code is doing trying to audit code that you're kind of like well I think it kind of does this you really need to understand the assumptions the rest of the code is making I mean going back I guess to a previous thing another like thing I often see is let's say you're counting the number of elements inside a mapping I often see you know plus plus and then set but this isn't or in the other direction - - and then set to zero and this is a huge problem because if you set the same thing twice you now think the mapping has to bytom's in it and so it's important to kind of be able to trace back and see well what code paths can get here to even do this maybe they're guarding it somewhere else maybe they're not maybe they should be checking like gas efficiency may or may not come to play so I don't know if I really answered the question but what seemed like good search do you have anything to add matter no that's that sounds very close to what I'm doing I mean it's very it's extremely time consuming to do it this way but really get to know the code read it read it read it read it until you know it's forwards and backwards and during that and try to have this aggressive mindset where you know that there are flaws in it you just need to find them other questions from the audience shout and I'll repeat oh no we have a microphone hi so we heard from Piper yesterday about package management for a solidity and in Python as well are you guys or anyone else looking into how we know if we can trust those packages especially as the standard library might be replicated with different package sets obviously today in the development world we just hope the code works and then we realize it it doesn't which may not be as big of a deal when it's not solidity well that's an interesting question and just will to add there is also the question that if you can we trust the standards because a lot of contract interacts with tokens for example and no one accounts for a malicious token that can implement this standard we can modify in some some way that exploits the the other counters so it's I'm not sure if I'm answering a question but kind of a bad I'm sorry it's it's hard to really trust everyone so it's kind of what marketing said you have to be aggressive you have to think that anything can break anytime you have the think that anyone is malicious anyone is bad and kind of go this way don't trust anyone I is anyone thinking about putting in that package management system the concept of this package has been audited and give some kind of a marking of what company audited it and of course the reputation for that company is Piper here III I mean my perspective at least maybe I'm not supposed to have an opinion since I'm running the panel but is that it's definitely true that systems like NPM are an unsuitable here you know you need a lot better control over the code you're running but I think step one and as I understand that ESPM implements that is you specify exact versions of the code it crypt graphically hashed you know so you know you're getting the right code I don't know if any of you know whether sort of metadata about auditing is is in scope or not with a metadata for whether a code has been audited and who it's been audited Byers is in scope for a package management system I don't know what level of metadata then so I guess the question is ask Piper the answer rather Thanks just over there I was wondering if you guys are interested in any other smart contract languages and if so what would they be we interested in any smart contract languages other than solidity is that great yep yes definitely I did look a bit into serpent contracts way back did an audit of the BTC relay but it's right now solidity is the one which most contacts are written in but I think it'll be actually a refreshing change when serpents hits the road properly Viper oh sorry Viper yeah yeah I had a fascinating chat with the lead developer of Vipers a day I think it shows a lot of promise I'd like to see more smart contract programming languages there are things I like about Souls II and things I don't I have a mental laundry list of what my perfect programming language would look like and the reason I don't write us is because I'm aware that 90% of the work is the tooling and other languages can have a bit to catch up with salasi before it's before they're sort of at the same level in terms of tooling maturity but I don't think like some of these continued domination is in any way it should and so I'm working on my own like a little language but more as a side project than anything the solidity is by far the most yeah mature and it's all those other things on top of it that you really want like you want the the ID ease integration and like syntax highlighting like writing a syntax highlighter is not a fun thing but it's something that you kind of want and that's something you just have to write if you're doing your own like random stuff I think another cool approach is to have languages which are less capable basically like Babbage which and I don't know the details of this but I I think that Babbage is a lot more restricted in what it can do but can thus provide a great safety about the you know potential post states after the execution great unfortunately that's all we have time for so thank you very much to my distinguished panelists thank you up next we have another panel on formal verification moderated by Rito drinkler you [Music]