Visualizing Security - Raine Revere

[Music] hi I'm Rayne Revere I am adapt developer and I have a particular interest in tooling and security and especially how we can use tools and education to evolve our ecosystem and create a healthier community overall so as I mentioned on the panel there are some heuristic approaches to visualizing and discovering where there are vulnerabilities in your contracts and that's what I'm gonna focus on we've had some great examples of formal verification and that's the kind of work that absolutely needs to happen in order to improve security in our field and there's also some low-hanging fruit and there's some tools that you can use in order to get some easy indications of where your contract might be failing or might be a security vulnerability so I'm going to give a couple examples of common attacks similar to the last presentation and I'm also going to talk a little bit about the different types of developers in our community and kind of offer a more human lens of how we talk about security and how you can listen to others talk about security and figuring out where they're coming from so the big question is how do you spot smart contract security vulnerabilities and so visualizing security on the one hand I mean it in the literal sense that we can create tools that give you a visual representation of where a smart contract might be vulnerable and in another sense I mean visualize in a broad way to see what is there to see what you didn't see before and any security vulnerability could be described as something that was there in the code that you didn't see before so anything we can do to help you see what's already there is going to improve security so some common attacks I'll cover this very briefly because you saw more detailed examples in the last presentation but array griefing or a denial of service attack there's another function that adds an item to that array then it can get so large that iterating over it will never complete you'll run out of gas which means any function that iterates over it potentially could be blocked that could be fatal for your contract the reentrant C attack should be called out value the re-entrance e attack allows an any external contracts or any external call is free to call back into any public functions so you have to be really careful you really can't rely on the state as was mentioned before for a reentrant C attack then of course under flow overflow very simple one but if you have an unsigned integer and you subtract a larger number from it you're not gonna get a negative number it's unsigned you're going to get overflow or underflow and so instead of getting a negative number you're gonna get a massively large number and that could really change the logic of funds that you're checking to see your available if a balance is available that sort of thing so what do each of these have in common just at a surface level they all have specific code smells so code smell it doesn't sound like a very formal term and it's true code smell is just some indication that there could be a problem here right and even if that's not a totally formal thing that's enough for us to investigate it's enough to say yeah we should look into this so if there are code smells it means if we can detect those code smells we can help prevent those errors now there's a couple ways of detecting code smells I'm gonna talk about them static analysis is a method of testing and evaluating a program without executing its code so this is huge if you can look at the source code of a program and you can make some observations about it that's gonna be really powerful and give you ways to detect some of these possible problem areas so the first step in static analysis is parsing the code so you have your source code and what you want to do is take that source code and get out an abstract syntax tree so an abstract abstract syntax tree is really you can think of it like a map of the code so your code has functions has state variables and if you have a map of all those functions that you can explore programmatically then you can write code that analyzes your code code that reads code that's static analysis so there's a lovely community-based project called solidity parser and this is probably the first step towards doing any static analysis is parsing the source code and when you parse the source code you get an abstract syntax tree and from that abstract syntax tree you can do quite a lot of things the one that I want to share with you today is a library that I created that was an experiment to see can we look at smart contract code and can we determine where those untrusted calls are made if any send or any untrusted call is a potential security vulnerability what if we could easily look at the smart contract code and tell where those calls are being made from so I created a small library called Sol graph the input is the abstract syntax tree that we got from the parser step before and the output is a dot graph something that can be made into a visual form so let's say you have a simple contract here's an example of a non-standard token but you have a constructor that you can it creates a million of those tokens and then you have some functions to withdraw or get balanced so key points here the withdraw function is clearly insecure you have that external call anything can happen with that external call and in fact there's no checks against that so that's a problem but you can't really tell that unless unless you're a developer and you know to look for these things but then other things are have no risk so the get balance function is constant a constant function can't change the state of the application so certain functions are no risk certain functions are high-risk let's see if we can have a tool to more easily differentiate those and to pay attention to what's important and ignore what's not important so soul graph as I mentioned is intended to take that abstract syntax tree and output a dot graph to easily easily visualize these functions and that's exactly what we get when you run this code through soul graph here we have the output from soul graph and this shows each of the functions in a circle and you can see the mint function is in gray that means its internal so we know that that can't even be called externally that's helpful to know and the get balanced function is in blue which means that it's a constant function so again state can't be changed that's pretty good to know that there's not a vulnerability there and the withdraw function is the one we really want to pay attention to that's highlighted in red and that goes to an untrusted call so it makes it quite clear that that's what's happening this is an image that's the actual output of soul graph this isn't something I constructed for the slides so you can run any source code through soul graph and anyone can do it even non developers this seems really helpful to be able to have an easy way this is the heuristic approach right not a formal completeness but a simple way to identify where the potential risks are if something like this had been run on the DAO for example you would have had a visual representation of where this reentrant see attack could happen and something that's such a small investment would have paid off in a in a really big way so there's also dynamic analysis I'm not gonna spend much time on that that's kind of analysis where you're actually running the code so unit tests are an example of dynamic analysis you run the functions you make sure that the output is what you expect it to be in certain use cases I'd like to say that we need more standardized unit testing patterns for solidity every solidity contract sort of has its own ad hoc unit testing but some things are pretty common across smart contracts access control what can the owner do that non-owners can't do what can certain participant subscribers people in different roles what are they allowed to do and who are the people that the contract should just throw for that's a pretty standard thing across smart contracts and we don't have a standardized approach so this is something that I'm I'm looking for from the community so that's my technical discussion and I'd like to share something that's a little less technical but I hope will help you have more of conversations about security and to introduce this I'm going to talk about what I call the three developer cultures so different developers have different values different perspectives they bring different truths to the table but they can also have different blind spots so the first is called the web developer the web developer has often uses languages like JavaScript Java PHP Ruby Python web developers value simplicity usability practicality they want to build a product I'm a web developer I want to build something that I can get out there and let users test the downside with the web developer is that because they often work in very high-level languages they don't have that intuition for things like an array out of bounds of spamming attack or these attacks that are very specific to the system and very specific to the hardware or the VM web developers don't have that intuition so that's a downfall when it comes to security so they may undervalue those things the systems engineer this is a great category because a lot of the folks on the foundation a lot of the folks doing a lot of the lower level EVM work EBM see their systems engineers they know the EVM they know the hardware in the talks yesterday when you're hearing about 64 bit versus 256 bit what the implications are systems engineers are experts at understanding the implications of all these details and they also have their potential blind spot which is that they can under value abstraction write a C++ programmer might say well you know everyone should know all these details about memory allocation and the risks that that are there and that's a great idea but the truth is higher levels of abstraction allow more people to develop applications and be effective and we should embrace abstraction so it's more about finding the right abstraction than getting rid of abstraction completely and the third group here is the academic and we have some great examples of formal verification and some approaches to this using F star y3 the rigorous solutions and these are really important to be able to establish mathematically and have proofs for the validity of certain applications now sometimes they can be impractical usually it's just that it's hard we don't have a lot of academics in the world offering these solutions and helping to integrate them into the community it's a minority group so even though they have perhaps the most important contributions to the security conversation this is a small group and their findings can be difficult to digest so they can have a lot to offer but it's it can be difficult for the rest of the community to figure out how to best incorporate that and truthfully I want to add one more there's a fourth developer culture and that's the non developer and the non developer is absolutely essential to having any kind of successful product right business marketing whatever it is it's a huge part of making this work and as a non developer by definition they don't know what things are hard and what things are difficult and what things are trivial so they're relying on the expertise of others and that's fine that's part of the system but we should understand that as a non developer they really need to trust us developers they really need to trust the academics and the engineers and unfortunately this group can be the source of a lot of speculation a great example I think was again the the DAO attack where the price of ether plummeted due to a bug in a specific contract this is sort of like if a website went down like if yahoo.com went down people saying oh god the Internet is broken so one contract is not the entire aetherium network and sometimes those technical distinctions can be lost and can lead to a lot of speculation so really my point with all this is let's work together we have different perspectives from different people about security and what's important and all of those are valuable in summary static analysis is a quick wave for low investment to detect code smells and be able to look at potential high-risk areas in your contract dynamic analysis offers other tools that are helpful and requires a little more of the unit testing patterns and then lastly the three developer cultures is a helpful way to think about the different perspectives and values that are being brought to the security conversation I'm Rane Revere thank you come say hi look forward to talking to you [Applause] [Music] you [Music]