Securing Ethereum

Devcon 1 · November 2015 · 20:35

Dr. Jutta Steiner and Gustav Simonsson present the work undertaken to secure Ethereum ahead of its launch. The Devcon 1 talk covers the security effort around the protocol and clients, including audits and testing, and how the team approached finding weaknesses before the network went live.

Speakers

Topics

From Devcon 1, hosted by Ethereum Foundation.

Transcript

hello so Gustav and I wanted to talk to you a bit so my name is yota we were heading supporting the security audit surprise who launched and good stuff and I wanted to talk to you a bit about what we've done from the SDF side in order to secure the network and make everything stable so personally I said security is a process so that's what we kept in mind when we thought about security it starts with the different implementations that were supported and by the by the theorem foundation particularly the Python client the C++ and the NGO client in

order to ensure a healthy network together with the yellow paper that that is a bit unreadable as some people say but nonetheless and serve very well as a process and posters we'll talk a bit more about that in order to ensure that the implementations are actually in in like comply with the formal specification then of course a big set of comprehensive tests that we implemented and also good stuff we'll talk a bit more about that cross client tests particular tests for the VM has a critical core component of the of the

protocol transactions and vaak test and Christophe and Dimitri who are around they did a great job in in achieving a very big coverage and then finally the thing that Gustav and I mainly worked on the the audits that we did prior to launch so where we work together with blockchain researchers academic researchers different professional security firms for which we use the big chunk of the budget from the from the race and the from the sale and the bounty program let me say a few words about the bounty program since we have one of the bounty hunter hunters here

Martino did a great job so that was an effort and is still ongoing where we engage the community to find and scrutinize find issues scrutinized the network so yeah as I said it's still ongoing and it's important that we continue the work that started prior to launch even now especially since we are still in the frontier phase so that's a bit of an overview what we did so as I said it started basically with the different implementations and last year then that was the moment when Gustav and I joined the team in December setting up the audit strategy and then the different companies so sit it'll least authority

they also did a very great job analyzing the economics of the network DejaVu who helped us with the Go C++ and Python audits and finally as I said the researcher so said Elena Andrew Miller it's how they they helped us with a lot of theoretical analyses so before I hand over to go stuff I want to talk about one thing that's particularly important for me which is diversity but not the sort of diversity you might think when you look around but the diversity of the network so when we started we hope for a very diverse network or not because it's essential when you think of when we find a bug we want to ensure that the network

can continue operating safely so this is how it should be but unfortunately the audit schedule has kind of more led to a picture like this where go is dominating so we launched the go implementation first because we were done with the officially kind of because we had finished the audit already but in in between we also finished the c++ audit and it's essential to keep in mind that a critical factor for the for the mining is the implementation of the block to mind function which depends on the

implementation so please get C++ miner up and running and if it's just because you wanna earn some money when go is down and the difficulty goes down alrighty yeah so what is watching security there's a great quote in the yellow paper from Gavin about how this one more invalid state some valid states in a boxing and the blockchain blockchain security is a very broad scope and earlier this week we had blood sample talking about security in terms of mining hole and proof of stake and

early today we had Alex levitron talking about peer-to-peer protocol so what I'll focus on here is just a few examples of how what the things we found in the consensus protocol so we're not gonna go too much into networking or mining but look at the the core virtual machine and the protocol and so a few examples but before that I just wanted to show this relation between the yellow paper and the clients so we started with kind of three main clients CPP golang and platform and they are based on the yellow papers they are

considering the yellow paper to be the the formal specification and they have implemented the virtual machine and the protocol based on that and the dll paper is also what the other tests are derived from so if you go to github we have this repository for protocol test cases we have a few thousand density at our blocks transactions and the virtual virtual machine and these clients execute these test cases and the tests were actually started when the proof of concept was started last year so during the development until the launch all

these clients have executed these test cases and they've also been used by other clients like java javascript and it has to be client to ensure that they compliant with the other protocol and there's also a source of feedback from the client so we will see one example where we found a a bug in the form of spec based on the clients where the clients were actually correct but the spec was wrong and this also relation between a C++ client and the tests in that a C++ client is used to generate the other test cases so we're just gonna go for a few

examples to see what we found during the audits and in the bounty program and some really rough categories could be said to be the consensus protocol in terms of logic implementation details like overflows we'll see one example of a and then I was first attack and a few issues that we found after the the launch so here's the first issue in the bounty program creating ether out of thin air so this one was I think at this time Egypt and I were talking about how to reward bounty program issues and we we were kind of thinking it's a pretty

critical thing because it kind of affects the the limited supply property of the theorem what happened was that the formal specification doesn't limit the the block number it's actually unlimited so the data type that was used in Angola was a big integer for if and there was a interesting bug that was found by by John a snake in the a bounty program back in February and what what happened was that so so the go implementation is using a golem begin for the block number and there's a a up

code a instruction in the virtual machine to get the block number on the stack and what happened was that you could actually put a a block number that was bigger than 32 by stir in your block header and that will actually be valid when he dislodged the block header from the RP the RP encoding that Vitalik machine is in his previous talk so it have to block them with more than 32 bytes and then when you grab that number on stack it would actually be a because that in a way that you could push a a negative integer on the stack this was a

example of how to how we kind of used the wrong data type in the sense that the film virtual machine is not defined to be I mean like begins to introduce it's defined to the speed 256 bit values but in in languages like go you kind of have to used to begin to get to model that so the error is actually what we can see the the girls are looking at here which is the the commented out to make sure that what we push back on the stack is a unsigned integer and the thing we see at the bottom there is actually the contract particle that

would trigger a decision and the result was that we can actually create unlimited amounts of either another short example is just a very simple integer overflow they found back in March this one was found by the security auditors the sugar security and it was related to the sign extended operator in developer which is used to extend an integer binary integer without changing the value or the sign and so what the Gold Line used to do back in March that

it converted it popped one of the arguments from the stack and would then cast that to announce that integer of 64 bits even though stack items are 256 bits so that was something you could easily overflow asana fiber and that would then cross a consensus issue with c++ clients or the Python client so we had a lot of these issues where we were disgusting begin to just two unsigned 64-bit integers for for convenience basically to make make implementation of instructions easier another kind of

class of issues that we had is the off by one error where one example is the gas limit yeah Vitalik mentioned this thing is the previous talk here that the protocol has a this gas limit in each block and the jello paper specifies how much this can grow so the miners basically vote and they can they can change the gas limit to go up or down but only within a certain interval and this is the different github for the fix through this issue so what happened was that we were not considering the case when the gas camp was going down only

when it was going up it's a bit of an embarrassing you should be fine when you're just completely off by one but there's a lot of examples like that and we actually had the same thing with past clients so here you see the code there for the fix there and the important important part is just that we changed the less than or equal and greater than or equal to less than sorry we change less than to less than or equal and vice versa you can't see the full differ because C++ doesn't have code standard for line length so they have very long lines so moving on

to another type of issue we also had some non consensus issues during the audits and this one was found by by Martin in the bounty program and it's a there was an issue that had nothing to do with the consensus protocol the clients were correct in the logic but they had a very unperformed part related to the jump test instruction and you could trigger this by making this contract where there is a single function that calls itself so you could pass it like 1000 we just call itself 1000 times and each time it calls itself it makes a external function call to make sure that you get

a new execution environment and if you compile this and then off post compilation manually inserted jump test instructions in the place right there then you would have this very very slow thing we're both going and C++ we're using a data type store basically jumped us during the execution of contract right and the one mango thing to notice that the cost is really cheap for jump diseases pay a single gas for one jump test and so what happened is that they were both using a set data type to store all the jump tests and when you had a new

execution environment in the virtual machine like when you do a external function call that data type was basically recreated so in a single transaction execution of the same contract you would yeah it would have to be recreated so what was change here was basically to use a map instead and also to cache it between executions within a single we're in a single contract a short example of how to not do your own crypto was found in the C++ client where we have a expect from NSA actually so I couldn't find this in the little in the ECDSA spec itself but its present in the

implementation guide from NSA yeah I've cut the first steps just to focus on the last step which is that there's a point about you have to check whether the derived public key is that point of infinity or not and I think that was the will anyway moving on we're pretty short on time so the fix for this was really quick in C++ where we just added a single check that was already filled to track this so if you just add check on that but the point of this issue is that it was really hard to find even though the fix is really simple it was hard to find because it's something that's

missing from the code so right so a short example but the formal spec we found a case where the form of spec was using the the floor function two-round signed integer division and that was a case where the clients were actually rounding towards zero when you design division but the form of spec was running to to the floor so that's the example I mentioned before where the clients kind of influenced back the specification another example also in the form of speck around the same instruction the same division it's the it's this edge case when you divide yeah - 50 rated 255 divided by minus 1 so this is kind of

realization you have sometimes when you're working with this and the problem is basically that the daily paper didn't specify this so you could do your your equally different workflow semantics and still be technically correct so we had to add a case to just you can see on the right hand side it's the stack stack item through pop so we had basically a special case for that so my time is almost up here so I'm just gonna show really quick thing which is that when we launched there was a a note about that it's not really safe yeah so the post-launch we found a few issues and I

just filled one really really quick thing here which is also found in the boundary program this was found off the launch in the Python client where the Python client was not following the spec for suicide so when when is if you suicide the contract to yourself you need to make sure that it's at the balance is zero well you need to make sure that is in any suicide so but if you suicide it to yourself then employ when you would actually still have that balance of the watch it's just one example we had post-launch and I let's skip for a few other examples here and this go directly to to some takeaways so don't don't make your own watching and

if you do it's a really good idea to have formal specification and multiple clients we've seen issues where we had a bug in single client two out of three clients we've seen a bug in all clients and we also seen bugs where the form of speck was wrong but all the clients are actually correct and some of the things you have to really think about this type the data types you use in the conversions off-by-one errors and also be really careful with cryptography because there's a lot of cryptography details that that are not specified in the form spec they are simply referenced from from the literature and future wives we want to add more audits perhaps on an annual

basis it will be great if we could include more lines in audits and also include these clients in the scope of the boundary program the current boundary program reward is like between half to ten a half a Bitcoin a time bitcoins and if you compare this to like a Google Santa program they they offer bit more in case if fine hemisphere they exploit so I hope that in like three years we can increase the boundary watch to match companies like Google or Facebook yeah I'll skip this one on this style yeah