proposal: static analysis tool for runtime pallets

[masapr]

Project Abstract

Runtime Pallets are modules for writing the business logic of blockchains in Substrate (a Rust framework for building blockchains). These are usually concise pieces of standalone code with relatively few dependencies and clear specifications, hence tractable targets for performing static analysis and verification. The code quality of a runtime pallet is crucial, as even minor defects can result in major exploits like DoS attacks or the stealing of funds by a malicious party. A static code analysis can help to automate the auditing processes and prevent introduction of defects throughout the software life-cycle.

Therefore we would like to develop a tool - SARP (Static Analysis tool for Runtime Pallets) to perform static analysis with reasonable soundness guarantees. In particular, we would like to target vunerability classes that are detectable using dataflow analysis techniques like tag analysis and taint analysis.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (bank details via email or BTC, Ethereum (USDC/DAI) or Polkadot/Kusama (USDT) address in the application).
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[CLAassistant]

All committers have signed the CLA.

[keeganquigley]

Thanks for the application @masapr it looks like you have an impressive team. A couple of initial comments:

• Our payment options don't include KSM, can you please choose an alternative?
• The RFP contains only one milestone but feel free to break it down into 2 if that would make more sense.
• Since you mentioned your team doesn't have prior knowledge on static analysis, do you plan to do research or can you expand a bit more on your strategy?

[Noc2]

Thanks for the application. We are definitely interested in this. I'm also sharing it with @bhargavbh. I believe you already talked with him about it. Apart from this, please take a look at the comments by @keeganquigley above.

[masapr]

@keeganquigley Thanks a lot for your feedback. We had anyway planned to start the project with a little research, resp. getting to know MIRAI and figuring out how to implement the checks with it. I split this research part now into its own milestone. This way our strategy should also be clearer.

Apart from that, I adjusted the payment method and I changed the license to MIT (as MIRAI is already under MIT).

@Noc2 Thanks, yes, we talked with @bhargavbh. We also talked to the developer of MIRAI, and it seems he will be helpful.

[bhargavbh]

LGTM. only thing i would add is 'document interesting examples for vulnerability classes" (which you may find in research phase) as part of deliverable-2 in M1.

Secondly, its not clear what "The tool will provide at least one check on each vulnerability class" in deliverable-1 of M-2. Could you please clarify?

[Noc2]

Thanks for the quick reply here. I have just one minor additional comment. Maybe you can also add the default deliverables 0b. (documentation) and 0c. (Testing guide) to the first delivery regarding the prototype code. This doesn't need to be a lot, but ideally, we have a few lines that tell everyone how to run the prototype and what it is. This way, we also have the default deliveries part of the application. Apart from that, see @bhargavbh comment above.

[masapr]

Thanks for the feedback

On the "The tool will provide at least one check on each vulnerability class"
What I wanted to say is, that we will work on these two vulnerability classes. I wanted to put at least one deliverable within the tool, but actually this is more than I can guarantee. After all it could happen, that after analyzing it, we realize it doesn't work or is very complicated. In this case we would document our findings.
I changed the text accordingly. Is it ok this way?

[bhargavbh]

thanks @masapr. The research phase would help identify any major roadblocks or limitations. I suggest proceeding to M-2 only if the results of M-1 are positive.
I am happy to approve the application.

[Noc2]

Thanks for the update. It might make sense, in this case, to initially only apply for the first milestone (2 instead of 3 approvals), and we issue a follow-up grant after this one. But I'm happy to approve it in any case and share it with the rest of the team.

[masapr]

I agree with starting M-2 only if M-1 is successfull. Should I keep the proposal anyway this way? Or should I remove milestone-2 in this proposal?

[Noc2]

In this case, feel free to remove the second milestone, and I will try to get it approved today (it requires only one additional approval ;-))

[masapr]

ok, cool. I removed it

[Noc2]

Thanks!

[semuelle]

LGTM

[github-actions]

Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions.

Before you start, take a moment to read through our announcement guidelines for all communications related to the grant or make them known to the right person in your organisation. In particular, please don't announce the grant publicly before at least the first milestone of your project has been approved. At that point or shortly before, you can get in touch with us at grantsPR@web3.foundation and we'll be happy to collaborate on an announcement about the work you’re doing.

Lastly, please remember to let us know in case you run into any delays or deviate from the deliverables in your application. You can either leave a comment here or directly request to amend your application via PR. We wish you luck with your project! 🚀

[masapr]

@bhargavbh @Noc2 a short update on our progress:

• We implemented a proof-of-concept for the incorrect origin vulnerability and documented this here.
• In the next 2 weeks we plan to write a similar example for the unsigned transactions vulnerability.
• After that we would wrap up the milestone delivery and make a plan for future work
• In a follow-up proposal we want to figure out the software design, resp. how a tag-analysis can be implemented, without being too invasive in the substrate code base. It should also be easy to use for developers (ideally they don't have to change their code at all). We think this task should be addressed first, before deciding on the exact conditions we want to verify. But let me know, if you think differently about this.
• I don't know how strict you are with the deadlines, but I hope the delay to the original schedule (0.5 months) is ok.

[bhargavbh]

hi @masapr. Great to hear the project is on track. The deadlines are usually not strict, delays are acceptable as long as there is progress being made. Happy to coordinate/ get involved in the tool design and positioning, once the PoC is complete. Cheers!

[masapr]

I submitted the delivery: w3f/Grant-Milestone-Delivery#880