The Superpower of Code Search for Deployed Contracts

Transcript

hey everyone I'm Gary I'm a software engineer at Electric Capital and today I'm going to be talking about the power of code search and how you can use it to audit audit contracts today crypto is on its way to becoming the largest open source ecosystem in the world but with that comes with a lot of challenges and complexities for developers and security researchers so what do I mean by this I'm going to go over some metrics from the ethereum ecosystem that highlight the scope of this problem so the number of smart contracts being deployed to the ethereum blockchain that are verified is increasing rapidly since 2020 that number has grown 5X

if you look at the sheer lines of code that all of those contracts consist of it's about 290 million lines of code which you know is a lot larger than many software stacks and also butts up against you know some other larger stacks and organizations around the world and if you take a microscope to look at what transactions are actually doing you can see that they're doing a lot more than they used to so if we look at how many contract calls the average transaction is making it's doing 3.3 times more than it did in 2017 and so this kind of tells us that uh the activity is actually happening on chain or becoming more complex and there's more composability as well

and if you look at the usage of storage and transactions the average transaction is using about 4.1 times more storage reads and writes than it did in 2017. so we kind of have these three problems where the amount of code is growing exponentially both in the number of contracts and in the lines of code and also what these contracts are doing is also becoming more complicated and more complex and so to help tackle these problems we decided to build code search for ethereum as a public good and the app is called code saw and so I'm going to go over some use cases that use a security researcher can use code

software to code slot for today to audit some contracts so the first use case the first use case I want to go over is finding some pesky re-entrancy attacks typically found in Forks of popular Market lending markets and so um this example here is compound V2 there was a version of it which had a re-entrancy bug in it and thankfully compound team patched it and was never exploited but there's a bunch of um protocols that fork this code and they didn't address the bug and so you kind of end up with this re-entrancy vulnerability and it's specifically you can find it with the function signature do transfer

out and so if we searched that on code saw we get back a bunch of contracts about like 300 and from there you can kind of poke through them and see if any of those are susceptible to the re-entrancy attack so on the right hand side is that if you click into the line you'll be taken straight to where it exists in the contract and then another re-engency exploit you can search for is the read-only re-entrancy um this one's like somewhat new it's been exploited a few times this year but essentially it it comes from view functions that are unguarded and typically view functions aren't guarded because they don't modify state but you kind of get this side effect

where um you know if you have protocol a and it has a view function that's unguarded and you have protocol B which depends on that view function there's a case where the contract State can be manipulated and then the view function returns inconsistent values and so that's specifically the case here uh with this function get virtual price which is part of curve and this function is intended to return like an oracle price for curve LP tokens but uh it's it's not guarded and so if you're depending on it you're possibly susceptible to read only re-engine C attack um and you know if we if we search for invocations of this function it kind of

tells us you know what contracts are depending on it and we get back about 800 results so there's a lot out there in the wild and then the next one that I want to go over is finding improper implementations of Markle proofs um and so you know the the rule of thumb is is to use reference implementations of data structures and algorithms um but sometimes you know developers choose to or have to roll their own implementation of these things uh and so this is a common use case for code saw where you want to go verify you know these data structures that are uh very important and critical to the functioning of a protocol have been actually done properly so you know you

can search things like merkoproof you can search for like Merkel verify Merkle tree or you know anything that makes sense and it extends also to like any other data structure and algorithm like red black trees and so on um and then you know you get back a bunch of results but for this one you know I think most people are using things like open Zeppelin but there is definitely instances where folks are rolling their own implementations and then the last use case I want to go over is uh this one actually is interesting because it came out a couple days ago um essentially uh a security researcher by the name of Zach obront uh published an audit in which he found that the prb math library and solidity had a bug in it

um and it was patched but um essentially on code saw what you can do is you can go and figure out what other contracts and protocols uh are vulnerable to this and have imported and deployed that buggy library and so specifically like there's this if statement here and in the buggy version it appears twice so some of these results you get two matches for it and it tells you that these contracts have been deployed with that buggy library and this is pretty cool because um there's not really a package manager that you know tells you all the versions of imports and stuff so one use case of code size to sort of fill in that Gap and you're able to kind of dig into the

supply chain if you're clever with the contracts and digging into the actual contents and you know creating these sort of divs and so after you find your contracts of interest you know we we also have some features on there which help you dig into the information about it and so this one right here is a chart showing the call dependencies of a contract um and so you know a lot of Protocols are multi-contract um end user typically interacts with like one contract but how it works like you know how it works um the contracts make a bunch of different calls to each other and so you get this like value flow and execution flow which isn't immediately uh obvious if you're looking just at like transactions and so we

created this Sand Key chart of the call dependencies and so it's constructed by summing the gas spent between in and outbound calls and so that's that's the representation the weight is represented um body thickness and then another thing you can look at is proxy diffs so this chart highlights the amount of upgrades amongst the top proxies in ethereum and so you kind of get this like upward Trend but essentially you know proxies and upgradable proxies are probably here to stay um and so on code saw if you're reviewing a proxy contract you can view the versions

of the actual logic contracts and then if the current and previous contract versions of an upgrade are verified you can also view a contract diff uh and lastly a little bit about the roadmap um we're kind of looking at it in two two ways one like unearthing more this information for devs and Auditors um so that's like uh next is to show contract storage um there's a lot of you know live State configuration state that also leads to exploits and vulnerabilities and so that's important to surface and then we also want to add annotations so that when you go view a contract there's already a lot of community wisdom or even like uh comments left by the team

so you can quickly understand like why they did certain things uh in the code and then on the other thing we want to work on is contributing to the data ecosystem so um you know planning to add contract verifications specifically for languages that are not solidity since the solidity ecosystem is pretty robust um yeah and lastly uh you know we can't make code slaw as best as it can be without your input so please give it a try let us know what features are missing or what you think could be improved thank you