ZK10: ZK Vulnerabilities and Attacks - Stefanos Chaliasos

Transcript

foreign [Music] so today I'm going to present I joined work with Jens David Muhammad and Ben focusing on vulnerabilities in systems utilizing zero knowledge proofs so the main incentive for attackers to finding and exploding vulnerabilities is the prospect of financial gains so far systems that utilize zero nodes proofs are only tiny fraction that contain only a tiny fractions of the total value locked in the blockchain ecosystem in general so although there have been some

pretty severe vulnerabilities in deployed systems we haven't observed any major attacks so far and another reason might be because like zaps are kind of difficult and until recently not many people actually worked on them two such examples are the zero the zikas counterfeiting vulnerability and then under constrained tissue in tornado cast so in this talk we are going to discuss a bit about the impact of zkp vulnerabilities layers in which bugs can be introduced and we also going to present a taxonomy of common zkp vulnerabilities and we will conclude

with a brief discussion about countermeasures and the defenses so to perform the taxonomy we gathered a bug report for various resources like the Xerox Park Community ZK bug tractor some blog posts some odd reports and also the backtrackers of major protocols in total we have gathered more than 100 bugs but so far we have only processed 45 bucks and in the following of this presentation I'm only going to discuss vulnerabilities that we can we have actually already studied a bug in a real world project

so uh Ziggy peace have three fundamental properties first one is soundness so this means that if a statement is false then normal is prover can convince a honest verifier that this statement is true but if there is a vulnerability in the verifier then maybe the seating approver can actually convince and verify the body verifier that a statement is true when in reality it's false and the impact of such vulnerabilities could be like for example in a project like tornado cast if we have something assist you then

maybe an attacher can basically get all the funds out of a pool the second property is completeness and completeness means that honest approver can always produce a valid proof for a valid statement and if we have a vulnerability or bug in the approver then maybe that can lead to denial of service attacks and finally we have zero knowledge which means that proof should not leak information about the private information and again we can have some sort of attacks at this property so to build uh Implement and use uh zkp application we have those layers the

base layer is obviously the hardware the operating system the runtime on top of that we have the proof system and here we're referring to basically the specification of a prefix system or the paper that describes the algorithms the inputs and all the details that someone should then Implement and the next layer is zkp tools and libraries such as the circum snack the yes tool chain hello two Etc where people can actually write circuits and this libraries typically use like a highly optimized low level field arithmetic and television libraries and on top of that we have the actual circuits that people write using

those Frameworks and the final layer is the ZK application with which users actually interacting so in this study we don't focus on hardware and field arithmetics and we also do not consider like any vulnerabilities that are not zkp related in the application layer so we don't care basically about Rangers vulnerabilities so far from the 45 bugs we have studied at 27 are in the circuit layer 11 are in the framework layer which is still a pretty big number for 45 bucks and then we have six bugs in the zkp application

layer and these are typically pretty easy to fix and also we have studied two bugs in the proof system layers and that could have like severe implications because any implementation that basically implements that proof system may be successful to some attacks and here is our taxonomy this is already a bit outdated but as we can see like most of the bugs are selling these bugs and this is the main thing in the ziki zkp space at the moment and I feel like uh those kind of bugs will be the target for some attacks in the future so if we go to the

application layer the first root cause of vulnerability is missing input validation checks and for example uh basically we can Harvest validity contract and then we forgot some require statement and that can lead to a completeness or a sadness issue on the circuit layer so far we have only studied uh some sort of other constraint issues so all those categories basically are under constrained issues and we have characterized them as logic errors if we can not include them in any of the more fine-grained and in the modifying grain categories and

for example here is an arithmetic overflow in a hello to program and with if we remove the constraint in the the second line then there might be some overflow issue that could lead to sadness back and the final and finally we have a framework in which there are two kind of bugs the first one is uh in the code that is generated from the framework to be used in the application layer and typically missing in with all these insects are that kind of bugs and we can have some lower level bugs such as quick Randomness compile optimization bugs Etc and finally in the proof system as we

already discussed those bugs can have like really severe implications in all implementations of those proof systems so what we can do obviously we can do auditing and auditing is a common practice in the whole block second ecosystem and definitely most of the biggest ZK Protocols are decoded but before auditing we should educate zkp developers and security researchers on zkvp's vulnerabilities and security related issues so there are already quite a few high quality sources that people can study and learn more about

gkps and dkp security and we can also develop better tooling so by better tooling we mean better dsls that people can write circuits which is the main issue in the space at the moment and yeah those dsls could eliminate some of the categories of vulnerabilities in the circuit level there is already some application of formal methods for detecting zkp vulnerabilities especially in the circuit level and as we can see like from the examples here most of these tools currently focus on the circuit level and mainly on sadness vulnerabilities

so what are the initial insights of this work first of all what we are missing is proof of concept exploits and we are currently working for all the bugs we have gathered to actually create reproducible proof of concept exploits and that's important for both developers but also for Tool developers that want good benchmarks for their tooling uh furthermore we have identified some primary sources of vulnerabilities and the first one is optimizations across all layers where we try to optimize some things and then something something else breaks mismatch is in full sizes some specific peculiarities of bsls and

libraries that are difficult when you are start writing circuit in DSL and also another common mistake is when we reuse a gadget or a component we forgot to properly constrain the inputs and the outputs of this gadget moreover we have identified some things that we need to improve with regards to tooling we think that the main tooling that it's currently missing is testing Frameworks and that's kind of expected because there are many moving Parts at the moment in the space but as the space becomes more mature we are expecting more testing Frameworks and another important point is that to detect some

particular bugs you might need to have tooling that can analyze both the circuit level and the application Level at the same time and finally bugs in lower layers can have catastrophic impact in all the layers above them so as a future work for this study we want to process more bugs and proof of concept proof of concept exploits to our data set and add missing vulnerabilities from the categories we have in taxonomy because there are some bugs we haven't still processed and also we wanted to integrate it with the Xerox spark GitHub backtracker and update it there

so in conclusion do we have to be stirred about what the future will be and the answer I think it's both yes and no yes because as more tvl going through zkp systems then attackers will have greater incentives to actually focus on the GB systems and there are also some difficulties like the random model for onboarding developers it's kind of different from other domains so that might be an issue also vulnerabilities are complex and hard to detect and there is also some lighting of better tooling that we need to develop but we also can be positive because

there's already a great efforts of developing better dsls and tooling and there are already many great researchers and auditing teams and related educational resources that we can use in the space so that's it and here are the main resources for this uh work thanks a lot [Applause]