Josh Hannan: Blockchain is a New Paradigm | ETHDenver

welcome to the second half of day one of East Enver is everybody having fun alright awesome so we we have another another several hours of workshops before we do the opening ceremonies this evening as a reminder we have a second stage over here with additional workshops and this of course is the main each stage our next presenter or presenters are from modular this is another smart contract security focused presentation as you probably know smart contract security is kind of one of the most important things that we need to collectively get right as an ecosystem and it's something that's very much up in the air right now and being developed so it's exciting to watch and exciting to see new services and tools being developed so with that I'm gonna hand it over to Josh and he'll dig into it thank you so welcome everybody to an introduction to smart con contract and distributed application security presented by modular and consensus my name is Josh Hannon and I'm CEO a co-founder of modular and I'm joined today by Jessica Marshall an engineer at consensus and we were gonna have will G s present today but as he missed his flight so we're having a Chris Brown who is the CEO CEO and modular take over for him so I just want to start out by saying that blockchain is a new paradigm that requires us to pave differently when than before when building these applications gone are the days when we can rely on the old Facebook adage of move fast and break things because we need to be slow and methodical and everything we do taking care and consideration when building these applications and we especially can't put ourselves under a lot of pressure to meet strict deadlines when building our projects good thing we're building a hackathon so um I just want to start out by going over a few aspects of the technology that require us to be so careful when we're building these applications because if you compare if you compare like old web design to like a minute clinic and you could kind of compare blockchain to like an emergency room sure there are some issues that are small that can be fixed easily but it's important that we focus on preparing against every possible negative outcome because anything that happened could be catastrophic and is extremely hard to fix so first thing I want to go over is that all code is public so this causes a few problems that we have to worry about first of all since your code is public that means that every all-star hacker is gonna be able to comb through every single line of your code to try to find possible vulnerabilities so there's no hiding behind precompiled binaries this time and this makes it vitally important that we make everything that we write as clearly written as possible so that when other people are reading it and auditing it and testing it they know exactly how it's supposed to behave so we can prepare against possible vulnerabilities another reason that this is a big deal is that we can't have sensitive user information on the blockchain sure it might sound good to you to try to want to put some user data on Shane to do some nice data analytics but that might not sound good to a little Johnny over here whose browser history was just exposed to the world on a public and mutable permanent ledger so you just have to be careful about that next thing she wanted to I want to talk about is that computation on the ethereum blockchain is expensive and there's also a limit so it's important we focus on keeping logic within our contracts relatively simple so that it can't be manipulated by attackers trying to find ways to cause transactions to fail within our smart contracts and last but not least on the blockchain we have to worry about immutability all code execute exactly how it was programmed and barring an unlikely hard fork actions taken on the blockchain are immutable so this is how we ensure Trust lessness in our code we program trusts into our code so that we can trust it and not each other in fact I'm starting to trust smart contracts more than I trust some humans smart contracts well lie to you smart contracts won't cheat on you and smart contracts won't post angry tweets at North Korea at 2:00 a.m. on a Tuesday I for one welcome our eventual global blockchain overlords but before we get to that point we need to be the ones doing the building we need to assume or we need to make sure that all of our applications are hacker proof script proof and even tackle literate grannie proof if our tech literate grandma accidentally posts for google search for hemorrhoid cream to Facebook it's not a big deal we can just delete it but if she accidentally exposes her public key because of a poorly written smart contract or application that's that's a lot bigger deal than in the previous situation and there's not much we can do once the damage has been done and unfortunately her tech savvy grandson Johnny can't help her because he's too busy trying to delete his browser history from the blockchain so in building these applications we need to make sure we need to focus on building every application assuming that everyone is is the tech literate granny ensuring that functions are all called correctly and operations are performed without error because you never know somebody might just accidentally take take control of your multi signature wallet library and suicide the whole thing so before we go into so before we go into specific examples about smart contracts we're gonna talk a little bit about application security and we've got a few vulnerabilities lined up or patients and emergency room that we're gonna look at we're the professor's and you're the doctors and it's exam day so let's look at some application vulnerabilities paging dr. Chris Brown we got a patient for you application vulnerabilities hey how's it going my name is Christopher Brown as as Josh said so we're gonna talk about a super-sweet game we'd developed a gaming platform that we've developed and of course security was our number one priority here but we need help in looking for what all the vulnerabilities are with this platform that we decided to build for game developers so in this platform developers can openly publish their games and then players can sign up to this application on your website and they can choose from a variety of games and then spend their ether on virtual goods so we're totally in the browser here nothing wrong with that right so we we create new wallets in the browser also no need for a made a mask or mist or anything that may be too difficult for the users we want to keep it simple and then with that we're gonna take the wallet keys and we're gonna store them into the players browser to enable micro payments so yeah super sweet setup right so let's play the game and let's see if we can diagnose any problems so we launched our platform and [Music] mr. part so players come in and they start you know you've got developers that put in some new games and players came into your platform and hadn't had no issues and everything was going great then all of a sudden a reddit post comes up and somebody's complained that their entire wallets being cleared of ether no big deal they can't quite put their finger on it several random addresses and transaction hashes out there but then sure enough a couple more people come on and they say you know we were playing on this platform that we develop and and all my ether was gone too then you got a dozen posts complaining about this new gaming platform and all of their ethers disappeared so of course we get on there at risk of losing 30 karma and just kind of respond with you know everything's fine nothing's wrong these people you know they must have done something on there and that exposed their wallets maybe they've got some malware on their computer or something surely it's not us because we paid attention to everything we were doing with this platform but of course behind the scenes where we're looking at what's going on here and we decided that there was problems caused by this new game called Auto quest that's somebody posted on our platform what we found through going through the logs and such that these wallets are actually being emptied within seconds of accessing this huddle quest game so in this game or let's backtrack this is kind of more about our platforms so in this platform what happens as game developers come on they put a name into the into the forum then they also post a smart contract to address at which they're distributed game execute logic and then they have a URL for the application for this new game so then our platform takes this information embedded in our application in the web browser and makes it available for players while displaying the games name at the top of the page so with this information can anybody kind of diagnose what problems this may cause that would allow somebody to get access to the players wallets any ideas okay yep anything else javascript objection yep so he mentioned that the Velva can inject JavaScript code that will are malicious JavaScript code anything else okay well hold too long because actually that's what we have up here so the developer and when he input the name we didn't scrub the the input and we allowed him to put this malicious script in there which will now go into the local storage in the U and the players browser and it will pull out the private key that we put in the local storage I know that this has been not this particular attack specifically but I know we've kind of gotten comfortable with information while in information in web browsers and I'll tell you you know local storage has never really been appropriate for any sensitive information it's it's got its purpose elsewhere and it's definitely something that we should consider when developing distribute applications and we're using web browsers as a bridge so let's kind of go through the security check list real quick so always protect private keys and wallets of course private keys unless you're using a multi-state contract gives you all of the funds tokens ether inside of inside of those wallets always of course protect user information nothing new about that [Music] unchain and off chaining information you know the blockchain of course it has its purpose right we we use it as a distributed ledger to record information that that we would like to convey to all of the participants but not everything has to be in the blockchain not every every process and function we just need the specific parts that need to be conveyed in a global in a global ledger and so you know considering what goes in and what does not go into the blockchain is important HTTPS this this is standard right it if you're if you're using a website that's taking any information anything less than HTTPS is is just not appropriate it's simple to get certificates nowadays of course when you're committing code and such we shouldn't be putting API keys into there we should make sure I get ignore is is up to speed on what we're trying to post and then consider using two-factor authentication when when it's you know makes sense for your application so great job thank you thank you for answering there and I will now page dr.

Jessica from consensus hi Ben Siegel alright so I'm gonna tell you guys a knock-knock joke okay you ready head nods ready great okay knock-knock raised condition so now that we're in the world of smart contract security for those of you who have even like peeked into the solidity documentation you know that this is a really really big problem for those of you don't know a race condition is a problem that arises in any any system but like here specifically in smart contracts where you think something's gonna happen in a certain order and then it doesn't happen in that order and then you have lots of problems so I'm going to talk about two race conditions in this presentation one of them being reentrant see the other being front running so let's start with re-entrance ii you guys remember the dow yeah so the dow hack occurred as many of you probably know because of a reentrant sea bug so what is re-entrance ii so you got a smart contract it's written in solidity you have a function right you think it's gonna do exactly what you think it's gonna do but then it doesn't basically anytime that your contract calls another contract and an external contract or really an external function that's untrusted you're basically you're letting your baby go right like at that point you don't know what's gonna happen because of that it's really really important to do all kinds of internal state changes before calling that external function because you don't know what's gonna happen because when you call an external function you risk control flow takeover then it could change your state and all sorts of bad ways and this can happen inside a function it can happen cross function and it can happen cross contract cool we got that awesome all right so real quick there's a couple of different ways to send ether around between contracts there's the transfer method there's the send method and then there's the call value method all of these will send ether from one contract to another but they've got a lot of couple of differences basically when you do when you would do an address dot transfer you're forwarding only a certain amount of gas and it will revert if it fails so basically a revert is just when all of your transactions unwind and nothing changes the reason is important that it only forwards 2300 gas is if this external contract hijacks your control flow it's not going to get very far send is kind of similar but instead of reverting on a failure it returns false it's also a little bit of a lower level method so generally we don't recommend using that we like transfer furnace we're called out value called out value like you're really you're really letting everything go if for words all of the gas that you've sent to that function so you're basically letting re-entrance e habits day there's a sub method within called out value where you can specify how much gas you're gonna send which could be useful if you if the 2300 gas that transfer allocates for you isn't enough awesome great so now you know how to send ether and you know about reentrant see now we're gonna look at a Regency attack oh no don't look at that okay so real quick you guys know to fallback function is so basically for those of you don't know a fallback function is is a function that you put in a smart contract that doesn't have a name it's why it's called the fallback function and you can make it payable so basically if you send ether to a contract if it has a fallback function it'll take that ether so sorry it's kind of small hope you guys can see it basically over here what we've got is a bank contract you have your your mapping of balances you have a constructor function that makes the contract happen you have the option to deposit and to withdraw right what could go wrong and so basically when you deposit it increments your the your specific addresses index in the balances mapping to whatever you you deposited the withdraw method does this thing over here basically there's an if statement and it says if message sender that's you dot call dot value so you're sending ether if and you're sending whatever is currently in your bank account bank account so basically what this is saying is if this fails revert right great except we got kind of a problem here because over here I've got my bank robber contract and I'm just gonna steal all of your funds so basically what I do in the in the fallback function I've decided I've imported your bank contract code basically if the bank's balance is more than what I'm trying to withdraw I'm just gonna call the withdraw method again but wait a minute isn't this supposed to fail right it says if if it doesn't work if I can if you don't have that your balances if you don't have that much money in your balance you shouldn't be able to call that function again right except down here we only increment you only turn your balance to zero after this lovely loop has taken out all of the funds from the contract so this is just like a really really typical example of a fall back of a reentrant C attack via fall back great okay now we got that the next thing we're gonna talk about real quick front-running so basically what front-running is it's a race condition attack that can happen because transactions don't have a fixed order in a block right so you send your transaction you wait for it to be mined in the meantime it's in a public pool right so that transaction is pending with a whole lot of other transactions that's fine right I mean the miner will get to it eventually except if you're doing something like a decentralized exchange and we know like half of you are gonna make decentralized exchanges in this hackathon this 2018 is a year of a decentralized exchange so because of that make sure you're decentralized exchange is not vulnerable to front-running attacks how do you do that right if I send my bid for a I don't know I want I want a three been token for to jest token and someone's like actually you know I'll give you one jest token for those three been token or the other way around they under at you you're kind of in trouble and if someone wants to attack you're decentralized exchange they're just gonna undercut everybody in in the transaction pool so a couple of ways to mitigate that you can do batch auctions or you can do commit reveal schemes where you send the hash of your your bid and then reveal that bit later after it's been mined great okay so now we're all experts we know all about Ranchin see we know all about front-running we got patient number two all right so if you guys have played youth or not you're not allowed to answer what we have here is a king contract it has two state variables and address the king and a you and a UN so an unsigned integer prize value so the way this starts is someone deploys the king contract and they send a certain amount of ether to it right so that the deployer message sender becomes the king and the prize value of the contract becomes whatever they sent to the contract now I want to be king of the castle but instead of what we did in elementary school where you knocked someone off the top of the hill you have to send more ether than I did to this account so basically what happens right so Ben Siegel here sitting in the front row wants to be king he doesn't want me to be king anymore so he's gonna send more easier than I did to this to this contract right it's gonna require that the the amount of ether that been sent is more than the prize value of the contract or it's gonna require that it's me sending it again but it's not in this case great so Ben sent more ether than I did he's a new king right except not next what happens is the current king which is me gets transferred the existing amount of funds that Ben sent me great so I just made money hashtag Ponzi scheme and then the new prize value is what Ben sent to the contract right I mean it's a transfer so can't really have reentrant CEATEC can we or can't we alright so if you want to take over this contract and you never want anyone else to be the king and you're willing to take the hit and just never never earn that new money what are you gonna do anybody have an answer have you played easier not you're not allowed to answer anybody anybody give you a hint it's with the transfer function now nobody not even Ben Siegel in the front row no oh it's okay Ben knows I love him now oh you have an answer he said I'm going to revert in my fallback function he's right that's one of the things I could do I could make a contract and I could have that contract become the king and program in that contracts fallback function that whenever anybody tries to send either to me I'll revert the transaction so great that's one way to do it now what is it what might be another way to do that same attack but without using a revert in the fallback function anybody I'll give you a hint it has to do with the fact that transfer only sends 23-hundred ether or 20 hunts 2300 way gas rather not easier that's a lot of ether anybody now yeah exactly I could put something in that fallback function other than revert what now I could put something in that fallback function other than revert that'll just like I could be ridiculous and make a recursive function and it will always error out of gas anyway so thank you that was great none of you are gonna have reentrant C attacks in your hackathon projects it's gonna be excellent all right so coming back to the stage paging dr. Joshua thank you so just to go off continue on what Jessica was talking about with fallback functions just when I have a reminder that as she said with the transfer function they only have access to 2300 gasps so well well that's important to focus on in other people's contracts it's also important that you in your own contracts that you don't perform too many calculations and your fallback functions because they could be manipulated if there's a loop in there or something like that they could be manipulated by attackers to cause transactions to fail but there's another catch to fallback functions in that there's a way to get around triggering a fallback function and this is the way an attacker can call the self-destruct function within their own contract which causes their contract to be deleted from the chain and fords all of that contracts ether to the address that they supply is a parameter and in this case it's your contract so what does this mean free either I'd take that any day but if you it's important to remember that you should not have any explicit checks in your smart contracts that expect the balance to be a certain value because you never know you might be richer than you thought all right so we're gonna go over one more thing in the EVM that we need to be concerned about and that's integer arithmetic the first issue that we need to focus on is when we're doing calculations with integers like division if we're worried about precision in our in our calculations we need to make sure that we're focusing on moving moving the decimal points to the right places so that we we can make the correct position precision when the calculate calculating percentages or other similar things because as most of you know when we're doing an integer division we only get integers in return and not decimals another issue that integer arithmetic and the EVM caused us to have to think about as integer overflow and underflow integer overflow occurs when a a computation results in a value that and I'll be represented by the number of bits in a certain location and this is a problem because if we have say a 256 bit integer in an addition operation if we add two numbers together and get it in a result greater than 2 to the 256 that will overflow causing the result to wrap around to 0 which could cause some weird issues in many parts of our smart contracts and this has been a problem that has caused people to lose lots of ether in in a few different hacks in the past but there's an easy way around this you can include checks on your function that check for overflow by simply just doing a few checks to make sure that the result is actually greater than than the operands but luckily you don't have to include this clunky thing in your own code because you have libraries to do that for you there are many options out there to choose from libraries but it's as simple as including the library in your code and calling functions from that library we have a suite of open source libraries that include a basic math library that does overflow and underflow checking for a variety of different applications and for addition subtraction multiplication division and you can use but we'll get to that later so who's ready to save a last patient you guys would make terrible doctors so and this for this example we have a snippet from a smart contract that deals with a dynamically sized integer array and we'll have three functions in this example that only the owner can call so let's look at the code so bonus codes is our integer array and in the first function push bonus code the owner can push code to the end of the array in the second function pop bonus code the owner can call it to subtract 1 from the length field in that array effectively removing the last entry from that array then our third function modify bonus code the owner can supply an index to that array within the bounds of the array in order to modify one of the entries in the array so I want everyone to look at this code for a few moments and then I'm gonna call out the name of each function and have people raise their hands if they think the vulnerability lies within that function so we'll just give everyone ten or fifteen seconds to look at this the patience slowly dying all right just as a hint think about what I just talked about some of the vulnerabilities we just discussed because that might lead you to the solution all right so everyone if you think the vulnerability lies in the first function raise your hand all right interesting choice second function pop bonus code raise your hand if you think it's in that one all right got a little bit more that time now who thinks that the vulnerability lies in the third function all right so we've pretty contested we got almost even amounts on the second and third functions but that's good because the vulnerability lies in both functions because this takes two transactions to exploit so in this in this contract we have this bonus codes array whose length can unfortunately be decremented below zero because in the pop bonus code function you subtract one from the length field but when we check at the length is greater than zero it's actually greater than or equal to zero so that would cause the length to underflow and become two to the 256 which then means that in the next function the owner could call modify bonus code supplying any arbitrarily high index they want which as I'm sure you're realizing could modify any location in that contracts memory and if you have other important stores variables in in your contract that could could be overwritten from this that could potentially be catastrophic so to protect against this you could either require that the length is only greater than 0 in the require line in the second function or you could check for underflow on the subtraction from the length field in the array or you could do both just to be extra safe but I would like to thank Doug Hoyt he this was his submission to the underhanded solidity coding contest and that's something that you guys should all check out there's a lot of great examples for some of these vulnerabilities and and some other intricate s-- vulnerabilities that are possible in the solidity language so what did we miss today the thing is we don't really know for sure there could be some small issue that we don't find in our contracts that ends up killing the patient or in our case costs us or our users millions of dollars in ether so the best we can do is to follow all the guidelines laid out in this presentation and in all the other great resources around the internet and around the world for best practices while building these distributed applications and smart contracts it's also important to remember that when we're writing our code we need to test extensively using great tools like debuggers and code coverage tools to ensure that we're reaching every possible state in our smart contracts so we can know that attackers won't be able to find it a small space in our contract they can sneak in and cause issues and last but not least we need to find engineers and teams who are who are experienced with security to audit our contracts especially if they are mission critical to get different eyes on them and find vulnerabilities in our code but I mentioned this before but there's another way we can ensure the functionality and security of our code and those are libraries solidity libraries before you sit down to write your code today it's important to realize that there are many other great engineers out there that have written similar contracts as you that are probably tested and audited and open source that you can easily integrate into your projects and with solidity libraries this is easy it's as simple as including that library in your smart tract linking to it on Shane and using the functions in the library as of it as if they were in your own contract we a modular have a set of open-source libraries over 20 open-source libraries that you can integrate into your project easily we have solutions for basic math tokens linked lists arrays and even crowd sales among many other things that you can integrate in your project easily you can just visit our repository which I'll give you the link to later to find detailed instructions on how to get started so I hope now everyone feels a little bit comfortable and feels a little bit better on being safe when you're building your applications but all that's left is to get out there and build something great but it's important to remember that this technology is still in its infancy and we're still learning things about blockchain technology about aetherium and about solidity every single day so it's important to always stay up-to-date on all the best practices and documentation around the web so that we always know when there are new updates that we can integrate into our coding practice so one of the best places to find smart contract smart contract best practices is content consensuses smart contracts best practices documents they include examples from vulnerabilities we talked about today as well as some others that we didn't get to and you can also join their Gator channel to join a discussion about it and and I've included a link to our aetherium library's repository if you want to get started there's details instructions on getting those integrated into your project oh I'll leave that up there for a second if anyone was wants to take pictures of it but you can also follow us on Twitter and we have discord channel which I'll show the link up up there next if you want to join the discussion we're working on building a secure desktop wallet that is extensible to multiple different applications and solves a lot of the usability problems facing wallets today while still giving users full control of their funds so here's the link to our discord our Twitter if you want to join the discussion but unfortunately we weren't able to save Johnny from a lifetime of browser history and due shame but hopefully if we follow all the guidelines outlined in this presentation we'll be able to save millions more from a similar fate thank you quick plug all of us all three of us on stage plus a couple more from modular will be walking around throughout the hackathon if you have questions and you want to ask about this in person that's all yeah well uh what later we'll have the modular guys we'll have orange shirts on that have our logo on it our products called blossom so you can find us can ask us any questions if you uh if you want to learn anything else or need help with your project we're always open answer questions I don't know how much time we have left right now but if anyone has any questions about security then we're happy to answer any yeah no you answer it well honey it's not that you don't want to call external functions just do everything internally first and I'll just sat on we we verify a source code on a thorough scan any time we post a library on chain so may net rank be Rothstein all of our libraries they're posted the source goes there and then ether scan the source code is the bytecode is verified so to cut the the functions can be seen as they are yep yeah we've used our libraries have been used in many different production applications and crowd sales so this is production test code that's deployed on all the networks so immutability we have our addresses on all our libraries on our repository so you can find those there that you'll be able to use and anybody else have a question yeah thank you all right thanks everyone