Skip to content

Commit

Permalink
more details on sw design approaches + deliverable with examples for …
Browse files Browse the repository at this point in the history 
…vulnerability classes
  • Loading branch information
@masapr
masapr committed Jul 17, 2023
1 parent bf0f18c commit fc5cad0
Showing 1 changed file with 13 additions and 12 deletions.
25 changes: 13 additions & 12 deletions applications/sarp-2-swdesign.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -115,25 +115,26 @@ In our previous work, we found the following problems:
3. **Invasiveness of tag analysis** The code we wrote in our PoC is very invasive and changes the code of the pallet. This is not practical for end-users. Ideally the user doesn't need to change anything on their code, or at least the changes should be very simple.

To address 2. and 3. we plan to evaluate different software designs. These will be part of our deliverables and we plan to discuss these with Parity and/or Web3 Foundation. The challenge here is the non-invasiveness of the solution. Specifically we plan to look into the following questions:
1. Is it possible to tweak MIRAI, so that we can run the analysis on pallets without modification?
2. Without tweaking MIRAI: What options do we have to separate the newly written pallet logic from the macro logic? Is it possible to do so, without changing the logic or adding artificial code (as the macros also connect the different functions of a pallet)?
3. Can we combine our findings of 1. and 2.?
1. Can we implement a preprocessing, that automatically annotates the pallet code for analysis in MIRAI?
2. Can MIRAI be tweaked to abstract out low-level details in the flow of function calls?
3. Is it possible to separate the newly written pallet logic from the macro logic? If so, is it possible, without changing the logic or adding artificial code (as the macros also connect the different functions of a pallet)?
4. Are there good combinations of the above approaches?

To address 1. we want to further analyze timeouts and crashes in MIRAI. Possibly they can be resolved by bugfixes in MIRAI. If not, we need to find workarounds.

Apart from the documentation of our analysis, we will deliver a first prototype version of our tool.

#### Deliverables

| Number | Deliverable | Specification |
|--------|-----------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 0a. | License | MIT |
| 0b. | User Documentation | We will provide a basic **tutorial** that explains how the tool can be used on the examples provided. |
| 0c. | Testing and Testing Guide | We will *not* provide a test suite with this milestone, but documentation on how to run our examples as in 0b. |
| 1. | Tool | We will provide a prototype version of the tool. Following the approach, decided in 3. |
| 2. | Documentation | Technical documentation of the tool, incl. reasoning on the design decisions. |
| 3. | Engagement | We will discuss different solutions and their implications with Web3 Foundation and/or Parity. For this we will document each approach with <ul><li>at least one example, incl. documentation on how to run it.</li><li>prototype code</li><li>analysis on the approach's invasiveness</li></ul> |
| 4. | Analysis of errors in MIRAI | We will document each error we encounter in MIRAI (specifically crashes and faulty analyses) with information on: <ul><li>how to reproduce it</li><li>reasons for its occurance and implications thereof</li></ul>This analysis will include the problems we discovered in the previous work package, but haven't analyzed yet (see [1](https://github.com/scs/MIRAI/tree/Milestone1_Research/substrate-examples/pallet_template#open-issues) and [2](https://github.com/scs/MIRAI/tree/Milestone1_Research/substrate-examples/offchain-worker#open-issues)). <br/><br/>We will report each issue in the [MIRAI repository](https://github.com/facebookexperimental/MIRAI), resp. provide a PR there. |
| Number | Deliverable | Specification |
|--------|-----------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 0a. | License | MIT |
| 0b. | User Documentation | We will provide a basic **tutorial** that explains how the tool can be used on the examples provided. |
| 0c. | Testing and Testing Guide | We will *not* provide a test suite with this milestone, but documentation on how to run our examples as in 0b. |
| 1. | Tool | We will provide a prototype version of the tool. Following the approach, decided in 3. We will provide examples for applying the tool to 3 of the following 5 vulnerability classes:<ul><li>[incorrect origin](https://github.com/bhargavbh/MIRAI/blob/main/substrate_examples/incorrect-origin/description.md) of dispatchable functions.</li><li>[unsigned transaction](https://github.com/bhargavbh/MIRAI/blob/main/substrate_examples/unsigned-transaction/description.md) validation.</li><li>tracking bad randomness: ensure bad randomness does not leak into sensitive functions.</li><li>detect panics statically to avoid potential DoS attacks: these include [unsafe arithmetic operations](https://github.com/bhargavbh/MIRAI/blob/main/substrate_examples/arithmetic-overflow/description.md), access outside bounds, assertion failures, etc.</li><li>tracking unsanitised input leakage for sensitive functions.</li></ul> |
| 2. | Documentation | Technical documentation of the tool, incl. reasoning on the design decisions. |
| 3. | Engagement | We will discuss different solutions and their implications with Web3 Foundation and/or Parity. For this we will document each approach with <ul><li>at least one example, incl. documentation on how to run it.</li><li>prototype code</li><li>analysis on the approach's invasiveness</li></ul> |
| 4. | Analysis of errors in MIRAI | We will document each error we encounter in MIRAI (specifically crashes and faulty analyses) with information on: <ul><li>how to reproduce it</li><li>reasons for its occurance and implications thereof</li></ul>This analysis will include the problems we discovered in the previous work package, but haven't analyzed yet (see [1](https://github.com/scs/MIRAI/tree/Milestone1_Research/substrate-examples/pallet_template#open-issues) and [2](https://github.com/scs/MIRAI/tree/Milestone1_Research/substrate-examples/offchain-worker#open-issues)). <br/><br/>We will report each issue in the [MIRAI repository](https://github.com/facebookexperimental/MIRAI), resp. provide a PR there. |



Expand Down

0 comments on commit fc5cad0

Please sign in to comment.