Smart Contract Security Tips - Joseph Chow

one line of code spurred a series of momentous events in blockchain history the line of code in red it was moved up to where the green line is and that was done to neutralize a re-entrant see exploit in the following line reward account dot payout which when performed on an attackers account would would lead to what happened to the DAO the description for this talk was before these momentous events and there's too much security advice to share not enough time that the BTC relay portion of this talk is omitted here's a bonus tip label your untrusted contracts so in the reward account dot payout account line already you can see that there are two accounts here and it's not as clear maybe immediately which account is untrusted so a better way to even rewrite this maybe is to reward account but payout untrusted account and then when people see that it can help help you be more aware of what might happen and as an additional tip message sender can also be untrusted so if it's always untrusted then you you definitely need to put a comment in your code that just to make people more aware the MELD allow simon Delarue be a and I start the committee resource for smart contract security tips we are grateful to seven others so far who have our listeners contributors in github the emphasis is on community because security is not just for a handful of developers to write about and the content needs to be aggregated and easy for people to find instead of being fragmented and scattered we start with some points about general philosophy before extending much further and getting more technical the first point is to prepare for failure the firt this is not about defeat or giving up this is to try to be ready for the unknown unknowns this can be very difficult to do but it is possible in some cases and the next slide is an example of this the second example the second point is to roll out carefully production a production system needs baking time in production the strongest swords are forged by repeatedly processing them in a process of putting them in fire and hammering them it takes time so for contracts they should be put through test nets and then a beta on maenette before a production launch on main net keeping contracts simple is an obvious tip but the process of simplification can lead to surprising results even in the system that already looks simple to stay up to date there's a bibliography at the repo for the community resource that everyone is welcome to contribute to be aware of blockchain properties is what the rest of this talk relates to as promised here's an example of preparing for failure the contract keeps track of its expected fund balance check invariants throws if the actual balance of the contract is smaller than the expected balance and this check invariance is called at the end of some of the key functions in the contract now the emergency call sends the balance to the workshop account only if the invariant is broken the invariant should not get broken but just in case it does the emergency call will send the funds away anyone can invoke the emergency call and the plan is to have a server call it every second if there is a breach that the contracts balance is smaller than what it expects the hope is that most of the funds can be sent to the workshop instead of being drained to an attacker contracts calling each other is powerful and can lead to emergent use cases but care must be taken for external calls that a contract makes the recommendation is to avoid calls to untrusted contracts as much as you can untrusted means any contract that you have not written this is because if you call someone else's contract they or one of their dependencies could accidentally call a malicious contract in the chain of contract calls all it takes is for one contract to make a mistake thus assume that untrusted contracts are malicious avoid calling do something or address call on an untrusted contract the key point is that after any untrusted call assume that the state of your contract has been manipulated here's a diagram to help there's a few things here but let's start at the foo function it decrements X and then it calls a an untrusted contract the fallback function of the untrusted contract executes and it can call foo this is an example of recursively entrance II it's important to realize that reentrant si can use any of the contracts public functions meaning an attacker can re-enter using the function G or bar this is why after the untrusted call the contract can't assume anything at all about the values of X or Y a second tip is to use sand and avoid call dot value if you've seen examples of vulnerable code especially regarding re-entrance e they all involve call dot value because using sand instead of call dot value does not give the attacker enough gas to do damage with reentrant see the attacker only gets 2300 gas with the great power comes great responsibility and that applies to call dot value and so the tip is to use scent and avoid call dot value perhaps the most mature best practice is to handle errors in raw calls Rock holes such as address thoughts and and address dot call return false if they fail this is unlike invoking a do something method which propagates an exception if it encounters one so the good example is to check check the result and the bad example is an unchecked send a tip that goes together with using send is to keep fallback functions simple the last fallback function is advised against because one it uses more than 23-hundred ass second it asks callers to break the tip of using sand and asks them to use the riskier call dot value a call depth attack can be used by an attacker to make all of your contracts calls to fail the theme the etherium virtual machine has what the yellow paper calls a contract a message called slash contract creation stack and it has a maximum depth of 1,024 an attacker can make recursive calls to bring the depth to 1023 call your function which brings the depth to 1024 and now all of your contracts calls will fail in this example simple example an attacker can force a recipient to lose their refund so the attacker recurse is to bring the depth to 1023 then calls withdraw refund using the address of a victim recipient and the depth is now at 1024 the refunds for the recipient will be set to zero this pointer doesn't work well to show that and when the victim calls withdraw a refund that the send will fail and then when the victim calls tries to withdraw their own refund the refund will already be set to zero so they can't get it back as an improvement the return value of send could be checked however a preferred solution is to write this contract so that message sender will pull their refund as opposed to the insecure contracts approach of pushing the refund to recipient this has had to be a quick presentation and there's plenty more information and examples such as pull over push denial of service against contracts and re-entrance e that can be found in the repo and wiki page to recap some of the main points for smart contract security are prepare for failure rollout carefully keep contracts simple and calling untrusted contracts is always dangerous the danger may seem small but if an attacker finds and exploits a bug in a compiler that is targeting the EVM they are likely to do much more damage if their untrusted code is executed then one where they only have a compiler bug to work with here are the links to a security resource of the community by the committee for the community I also have slides regarding denial of service and pull over push or can take two questions in the remaining three minutes any questions ok I can quickly go through a couple more so so quickly in this a denial of service against the contract there are many ways that pitfalls that you can encounter them one is an unexpected throw which is what this code example here is about but hitting the block s limit is another example iterating through an unbounded to raise another example misunderstanding gas refunds will also cause the same issue so in this example contract the the line with the throw means that a current leader that refuses payment will permanently be the leader and the throw cannot be removed in this case because otherwise some other person can do a call depth attack against bid and what that means is that they will get to be the current leader without having had to pay the previous leader so in this example you can just remove throw and for the final tip that we only have time for here is to change this into a pull over push system and so the left side is the auction contract that was shown this couple of slides ago this time instead of doing a sent to the recipient it just the contract just keeps track of the refunds that that are owed to whoever the highest bidder is and then on the right side is the pull method where everything works based off message sender and by doing this an attacker can basically only attack themselves so that's it you