Evolution of Smart Contract Security in the Ethereum Ecosystem

[Music] hey everyone thank you so for those of you who don't know us at sapling we build technology and provide services to help protect smart contract development we're mostly well known for our security audits but we also have some products and we maintain the open sapling repo of smart contracts so this talk will be divided it first I'm going to review last year since DEFCON 2 in terms of how the smart contract ecosystem evolved I'm then going to focus on some new techniques on patterns we've seen arising in industry that I'd like to get more visibility to and finally I'm going to talk about some pending challenges it's my contract security and hint into some possible solutions were working on so let's start with history the dark ages so 2016 was a pretty dark year for smart contract security we've seen some pretty embarrassing hacks in the space most of you probably don't remember many of these except for the Dow but just to get a sense of how the industry was at that moment I want to focus on one of them specifically which is Rubik's II so Rick's it was a formalization in a smart contract of a pyramid scheme the original name was dynamic pyramid but apparently the developer didn't think this was a good name for marketing reasons so he renamed it to Rubik's II which is much cooler but he forgot to rename the constructor and this male this made it turn into a public function because that's how solidity works so anyone could call the dynamic parents function and become the owner that's gaining gaining the ownership of the contract and being able to steal the fees from the contract so this seems like a dumb mistake but the same feature from solidity probably cost the party wallet hack which happened recently and cost like 30 million to be lost to hackers so in in in May 2016 a picture of SNS wrote a great girl calling the community to gather around a building best practices for smart contract development and one month later the dalek occurred the contract held roughly 15% of all ether tokens in existence and fifty million dollars were lost and at that time the only solution at the moment was to hard fork the protocol so a theorem had to hurt fork which in turn brought a lot of complications and security problems so it was not a good outcome in the end so at that moment the the the community was pretty aware that we need to ramp up our security practices and three months later on September we launched open sapling as a community effort to gather around auditing contracts creating better security practices and actually gather some smart contracts called to share a week later I was in Shanghai for DEFCON 2 and everyone loved the idea many projects wanted to gather around open sapling and help these contracts and since then the project has been growing quite a lot for the past three months we had more than 8% a weekly growth which is the hockey stick figure every Silicon Valley entrepreneur wants but the truth is we built something that everyone was wanting and the industry grew a lot say since then so it grew with the industry apart from the community building better tools for smart contract development in Syria massive platform evolved a lot too we've seen the consolidation of the various standards like they are seat 20 proposal that turned into a IP 20 for tokens standard also the platform fixed some security problems like the nasty call stack attack that was possible before and after AI PE 150 it's no longer possible also solidity the the most popular smart contract language got some cool new features in terms of security the payable keyword that allows to set when a contract can or cannot receive money require an assert that are really useful for setting the preconditions and postconditions of our functions transfer which is a safer way to send money from our contract revert to cancel execution of our function without wasting all the gas Purim view which are the evolution of the constant keyword and allowed to specify if a contract if a function can or cannot read or write state from the contract we've also seen the death of serpent as a language after a knowledge within which in which we found eight pretty serious vulnerabilities which led us to find critical vulnerability in the rep token which allowed any attacker to freeze the contract forever and male made them have to me migrate the rep token to solidity the serpent language was deprecated after this tweet from metallic and now although all the efforts around and an alternative language are focused on Viper which is a serpent successor and it's pretty cool so you should check it out it's not production ready yet but I hope it gets more attention and more recently with the Byzantine heart fork some consequences on on security are the region of begin sugar modular exponentiation which allows RSA signature verifications we'll see what people come up to with this new tool the asian of the static called opcode which enables safer calls to untrusted contracts because it makes them not able to modify your storage and the asian of up codes for data handling and revert the river top code allow for much easier and Tyler ways of implementing upgrade ability proxies which is an ongoing discussion topic in smart contracts security so that's what happened and now I want to focus on some new techniques and patterns we've been seeing on our audits and work with opens happening oh can you see that ok let's say you're a developer running solidity so you create your own you RC twenties all come for fun by using open selling you can do this pretty easily with like ten lines of code so you think you want to add something that sort to make talking cooler just for fine you think you want your token to have an extra functionality of being able to lock funds for a certain amount of time and you want to add a little extra gold as possible so a way to do this is to add a lock function a public lock function that instantly transfer the tokens but then stores when those tokens should be released and then modifying the standard transfer functions to make them honor this new extra restriction on that so let's see how this would look on coal we had this I don't know if you can see this but you had this a new log function which basically calls the standard transfer function and then adds in a in an array of blocks for each address when those funds should be released and then what we need to add to that is overriding the standard transfer functions adding this extra restriction where which via DS can transfer modifier which checks the amount of transferable tokens at a certain point in time and enables or disables the transfers and then to implement this a transferable token amount what we do is we iterate over the array of locks for every ad for that address and we add up the amount of locked tokens and we we return the total balance - the locks oaken's so in this way apparently we added a cool new feature to our token and it seems great but it actually has a big problem did anyone can even tell me what the problem is good good you want a t-shirt so we have a case of a gassy array as we like to call it the problem with this array is that the length of it is controlled by anyone that can call the log function which is in this case is public so you need to see the length of the array as a user input and as you know in security you need to sanitize inputs and any anyone can call the log function and create lots of locks in the array of of someone they want to mess with and the array if in this case I tried it and if you like 5,000 logs to Anna to an address the gas cost of calling a transfer for that token is so high that it doesn't fit in a block so the point here is I'm sorry by adding an extra feature we actually introduced a security vulnerability so there's a simple fix for this which is adding a an upper bound to the amount of logs for every address but I wanted to make you think about a different approach to adding features to a tokens which solves this problem in particular and I think it's better for security conceptually so the idea is to leave the token assist don't any extra functionality and actually implement the the locking functionality as an external contract so when a user wants to lock tokens for another they instantiate one of these new token time lock contracts which received the beneficiary address and the release time and then transfers the the tokens manually from the from the normal token contract and now if in this case the the previous vulnerability with legacy array was solved but if there were one vulnerability in this new contract only the users using this extra feature would be affected whereas with the previous version any vulnerability potentially could affect normal users that didn't want to use the lock function so this is one of the patterns with sin in terms of improving security in new function design and the point is when you're thinking about adding new features to your contracts really think about the security implications not always having more features is better because you increase the attack surface and for another example of how this has been implemented in the industry at the beginning of the year most crowd sales were implemented as part of the token code and now most most crowd cells are implemented as a separate module so it if you think about it doesn't make sense to have all the crowd sale code in the token forever for just two weeks or two minutes of course he'll finally this I want to talk about some the relation between basic security software engineering practices and more under security these are very simple stuff but they are not being applied in in our industry and I think this is basic stuff we should be doing so first is clear and simple code is always better for security while security problems come from a difference between the programmers intention and what the code actually does so having clear code makes it easier to check the programmers intention and that the code actually does what he wants a corollary of this is that naming matters have seen really really bad naming in many contracts so please take your time and think about naming because it helps increase the security of your code reuse existing audited call there's plenty of good libraries out there you can reuse there you can't imagine how many times we reorder at the same re-implementation of GRC 20 standard tokens also don't copy paste code because if the code you're using is updated you don't get the updates and also don't repeat yourself that's also a source of bugs and finally and most importantly write tests that's the best way to check that your assumptions about the code are correct and also if you change the code after the fact you can prevent regression errors so as I was saying all these are basic security I mean software engineering practices that every developer should be doing but in our case our code manages real money so we need to protect it from ninja hackers stupid users and other developers in our team so I want to talk briefly about the relation between security and trust reduction let's say you're a freelance solidity developer and your client requests a cupped crowd sale so you write this simple contract I think he comes and say oh wait don't forget we need to create tokens for the foundation to when the crowd cell finishes so you go sure boss you have you make your crowd sale ownable so it has an owner and a privileged function to mint the Foundation's tokens once the cup is reached so only if the cup is reached will it mint tokens but then your client comes back and says oh wait but make it trustless I don't want to be the owner so you remove the privilege function put it into the buy tokens function so that the last investor when the cup is reached means the token for the foundation this is better right it's more trustless wait now an investor can come after a cap is reached and with this particular call if the message value equals to zero they can continue calling this buy tokens getting zero extra tokens but remaining tokens for the foundation ruining the crowd sale the point here is it's not always good to leave critical when I relate a critical functionality of your contract in the hands of the public it's sometimes ok exactly sometimes totally ok to live really critical stuff from your smart contract in the hands of an owner especially if they if the investors or users of the contract are already trusting the owner in some other way like giving the money I wanted to say that so I want I want to end with some open problems that we see in the industry and some ideas were working on to solve them I briefly touched upon some of this but one of them is upgradability or both in terms of how to upgrade a smart contract once it has been deployed to the network for like bug fixing or adding extra features interoperability it there is contracts calling them each other the gas costs of how contracts interact within each other and code duplication in the blockchain so we recently announced our sibling OS project which tackles these four problems and I'm gonna tell you how we do that how we plan to do that so for code duplication basically what we're going to do is turning open sapling the library into a non chained library were applications kind direct directly connect and Link contracts to their own chain version to reduce the the payload that needs the white code that needs to be uploaded to contract on chain and all the other that are reusing open civilian standard token implementation they can share the same code on chain and release the gas costs of deployment and reduce the amount of storage needed and this kernel will also have an upgrade ability mechanism a via the delegate proxy pattern so that we can do upgrades to this kernel of really core and important modules from the ecosystem so we find a bug or or we need to improve some of the code from from those core libraries we can do so and possibly fix a production code from some contracts and of course this business a governance mechanism because a nobody would use some something that is in the hands of a few developers which upgrades are approved and by the way we we did this the technical research for this we did with the Oregon guys and they've been using the same idea on Eragon OS so you might want to check that out too and to two other components of the OS are the scheduler and the marketplace so the scheduler solves the gas the gas problem of smart contract interaction and it comes from the idea that when two contracts interact if you think about who pays for the gas price for those interactions for example a typical example nowadays is a multi-state contract controlling a crowd sale contract some privilege function for example finalizing the crowd sale if you think about it the first let's say you have three of five volt EC the first owner proposes to make the call the second one signs it off and when the third one signs it off the actual operation is executed another gas cost of executed that is paid by the third or the last owner of the multi C so with the scheduler we're building tools to enable contracts to request a synchronous operations in the future so a multi could gather all the signatures and then request someone else to do the actual execution of the operation so with a couple who pays for gas and who is actually approving the calls and this same mechanism also allows for a synchronous programming in general not just this this thing this thing is gas but enables a smart contracts to to request operations in the future and for the marketplace we are standardizing the way contracts interact with each other so we think that there's a bigger potential for smart contracts when they start interacting more and we see an ecosystem of contracts interacting and we're standardizing the way a contract can expose its services in terms of I this contract offer this API call for a monthly payment or a one-time fee and you get access to everything or a per call fee and finally part also part of sibling OS is a set of of chain tools which we call the smart contract SDK which are basically CLI tools and web applications to manage easy more easily your contracts so you can know know more about this it's a completely open source project we encourage everyone to participate in by giving ideas and cold and we can talk about more about this later finally we're not yesterday we launched solidity culturally flag contest we're giving away 10k in prices it's a hacking contest like there's a couple of contracts you need to hack to advance the next level so if you want to check it out and it's it's fun and that is all thank you very much [Applause] [Music]