From 3632049a4d743a47242e34c1dee162d273c7f5b2 Mon Sep 17 00:00:00 2001 From: Arnaud Date: Mon, 14 Apr 2025 14:12:13 +0200 Subject: [PATCH 01/14] Initiate treat modeling document --- evaluations/threat-modeling.md | 288 +++++++++++++++++++++++++++++++++ 1 file changed, 288 insertions(+) create mode 100644 evaluations/threat-modeling.md diff --git a/evaluations/threat-modeling.md b/evaluations/threat-modeling.md new file mode 100644 index 0000000..dd35034 --- /dev/null +++ b/evaluations/threat-modeling.md @@ -0,0 +1,288 @@ +# Threat Modeling + +## Introduction + +The goal of this threat modeling is to identify potential security vulnerabilities in the Codex protocol, enabling us to take actions to mitigate them. Additionally, it can serve as a starting point for directives in a security audit. The scope includes the [Nim codebase](https://github.com/codex-storage/nim-codex) and the [marketplace smart contracts](https://github.com/codex-storage/codex-contracts-eth). + +## Methodology + +The [STRIDE][1] framework is used due to its simplicity and the ability to quickly build an analysis. +The [PASTA][2] framework was considered but is more business-oriented and suited for mature projects. Additionally, its process is heavier than STRIDE's. + +Threat modeling is an iterative process, requiring constant updates as features are added or modified in the codebase. Documenting potential security vulnerabilities helps developers to keep them in mind during the code implementation. + +Anyone is invited to contribute to this document, as it is a [collective effort](https://www.threatmodelingmanifesto.org) rather than a one-person task. + +## Analysis + +| Category | Threat | Description | Impact | Mitigation | +|-----------|--------------------------|-----------------------------------------------------------------------------|----------------------------------|-------------------------------------------------------------| +| Spoofing | Phishing-Induced Spoofing| Exploits the private key loaded directly into the app via phishing to send unwanted requests. | Draining the user's wallet funds, store unwanted content. | Use cold wallet. | +| | Same-Chain Replay | Reuses a signed request on the same chain to spoof user actions. | Drained wallet funds. | Include a unique nonce in request data. | +| | Cross-Chain Replay | Replays a signed request on another chain. | Drained wallet funds. | Implement EIP-712. | +| | Client Spoofing via API | Access to the exposed node to use the API. | Node full access. | Educate users. + | +## Spoofing + +### Phishing-Induced Spoofing + +#### Scenario + +When starting a Codex node, the user must load his private key to pay for initiating new storage requests. This private key is loaded into memory, and there is no authentication process to use the REST API. An attacker could reach the user via email phishing, pretending to be from Codex. The email might redirect to a malicious website or include a form that, upon the user's click, triggers a request to the Codex node to create a new storage request. + +``` + ────── + ─│ ─│ ┌────────────────┐ +│ │ │ │ +│ Attacker │───────────▶│ Email phishing │ +│ │ │ │ + ─│ ─│ └────────────────┘ + ────── │ + • │ + • │ + • ▼ + • ────── + • ─│ ─│ + • │ │ + • │ User │ + • │ │ + • ─│ ─│ + • ────── + • │ + • │ + • │ Clicks on the phishing email + • │ + • │ + • ▼ + • ┌────────────────┐ + • │ │ + • │ Unsecure form │ + • │ │ + • └────────────────┘ + • │ + • │ Submits the form + • │ + • │ action=/storage/request/CIDMalicious method=POST + • │ input name="pricePerBytePerSecond" value="100000" + • ▼ + • ┌────────────────┐ + • │ │ + • │ Codex node │ + • │ │ + • └────────────────┘ + • │ + • │ POST /storage/request/CIDMalicious + • │ pricePerBytePerSecond: 1000000 + • │ + • ▼ + • ┌────────────────┐ + • │ │ + •••••••••••••••••••│ Contract done │ + │ │ + └────────────────┘ +``` + +Edit/view: https://cascii.app/437bc + + +#### Impacts + +This could lead to two issues: +- **Financial Loss**: Malicious requests drain user wallet funds +- **Unwanted Content**: Attackers force storage of insecure or illegal files via malicious CIDs, risking legal or reputational harm. + +#### Mitigation + +Typically, such web phishing attacks are mitigated by authentication or a [custom header](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#employing-custom-request-headers-for-ajaxapi) to verify the request’s legitimacy. + +However, Codex does not have an authentication mechanism, making options like CSRF tokens impractical and using a custom header would provide a poor user experience in Codex, as users would need to set the header manually, which is cumbersome and error-prone. + +Users can reduce the risk of significant fund drainage by employing a hot wallet with a small amount of tokens designated for storage requests, while keeping the majority of their funds in a cold wallet. This limits the exposure to phishing attacks, as only the tokens in the hot wallet are at risk. For example, a user might allocate just enough tokens to cover typical storage needs, minimizing potential losses. + +While this strategy mitigates the financial impact of unwanted storage requests, it does not address the storage of unwanted or illegal content. An attacker could still trick the user into storing harmful files via phishing. + +### Same-Chain attack replays + +#### Scenario + +An attacker reuses a user’s signed `StorageRequest` on the same chain to spoof additional requests, attempting to drain funds. + +``` + ────── + ─│── ───│ + │ │ + │ │ + │ User │ + │ │ + │ │ + ─│── ───│ + ────── + │ + │ + │ + │ Storage request + │ + │ + │ + ▼ +┌──────────────────────┐ +│ │ +│ Codex node │ +│ │ +└──────────────────────┘ + │ + │ + │ + ▼ +┌──────────────────────┐ +│ │ +│ Request signature │•••••••••••• +│ │ • ────── +└──────────────────────┘ • ─│ ─│ + │ •│ │ + │ •│ Attacker │ + │ │ │ + │ ─│ ─│ + ▼ ────── +┌──────────────────────┐ │ +│ │ │ +│ Smart contract │ ◀────────────────┘ +│ │ +└──────────────────────┘ +``` + +Edit/view: https://cascii.app/8edc1 + + +#### Impacts + +- **Financial Loss**: Duplicate requests drain user funds + +#### Mitigation + +Include a unique, random `nonce` in the request data. This ensures signatures are unique per request, preventing reuse on the same chain. Codex’s current implementation includes this, fully mitigating the threat. + +### Cross-Chain Replay + +#### Scenario + +An attacker captures a user’s signed `StorageRequest` from one chain and replays it on another with an identical `Marketplace.sol` contract. The signature, publicly visible in blockchain, validates without needing the user’s private key, spoofing their intent. + +``` + ────── + ─│── ───│ + │ │ + │ │ + │ User │ + │ │ + │ │ + ─│── ───│ + ────── + │ + │ + │ + │ Storage request + │ + │ + │ + ▼ +┌──────────────────────┐ +│ │ +│ Codex node │ +│ │ +└──────────────────────┘ + │ + │ + │ + ▼ +┌──────────────────────┐ +│ │ +│ Request signature │ +│ │ +└──────────────────────┘ + │ + │ + │ + │ + ▼ +┌──────────────────────┐ +│ │ +│ Smart contract │ ────── +│ │ ─│ ─│ +└──────────────────────┘ │ │ + │ ••••••••••│ Attacker │─────── + │ • │ │ │ + │ • ─│ ─│ │ + │ • ────── │ + │ • │ +┌──────────────────────┐ • │ ┌──────────────────────┐ +│ │ • │ │ │ +│ Chain 1001 │••••••••••• └───────│ Chain 1002 │ +│ │ │ │ +└──────────────────────┘ └──────────────────────┘ + +``` + +Edit/view: https://cascii.app/d312b + +#### Impacts + +- **Financial Loss**: Replayed requests on another chain drain user funds + +#### Mitigation + +Implement EIP-712 to include chain-specific data in signed storage requests, ensuring signatures are valid only on the intended chain and preventing unauthorized replays on other chains. + +### Client Spoofing via API + +#### Scenario + +A user starts a node locally and uses `api-bindaddr` with the value `0.0.0.0`. Worse, he confuses port forwarding and enable it for the REST API as well. + +``` + ────── + ─│── ───│ + │ │ + │ │ + ││ User │──────────────────┐ + ││ │ │ + │ │ │ │ + │ ─│── ───│ │ + Starts with 0:0:0:0 │ ────── │ Enables port forwarding for REST api + │ │ + ┌───────────────────┘ │ + │ │ + │ │ + │ │ + │ │ + ▼ ▼ + ┌──────────────────────┐ ┌──────────────────────┐ + │ │ │ │ + │ Codex node │ │ Codex node │ + │ │ │ │ + └──────────────────────┘ └──────────────────────┘ + ▲ ▲ + │ │ + │ │ + ────── │ │ ────── + ─│ ─│ │ │ ─│ ─│ +│ Attacker │ │ │ │ │ +│ on same │────────────┘ └─────────────────│ Attacker │ +│ network │ │ │ + ─│ ─│ ─│ ─│ + ────── ────── + +``` + +Edit/view: https://cascii.app/1cca0 + +#### Impacts + +- **Node full control**: Attackers can send unauthorized API requests, draining funds or storing illegal content. + +#### Mitigation + +Educate the user to not use `0.0.0.0` for `api-bindaddr` unless he really knows what he is doing and not enabling the port forwarding for the REST API. A warning during the startup could be displayed if `api-bindaddr` is not bound to localhost. + +[1]: https://owasp.org/www-community/Threat_Modeling_Process#stride +[2]: https://cdn2.hubspot.net/hubfs/4598121/Content%20PDFs/VerSprite-PASTA-Threat-Modeling-Process-for-Attack-Simulation-Threat-Analysis.pdf \ No newline at end of file From bb4cc01b47c5195984ac01b14b9d13e176f92790 Mon Sep 17 00:00:00 2001 From: Arnaud Date: Wed, 16 Apr 2025 16:15:01 +0200 Subject: [PATCH 02/14] Add tempering threats --- evaluations/threat-modeling.md | 502 +++++++++++++++++++++------------ 1 file changed, 317 insertions(+), 185 deletions(-) diff --git a/evaluations/threat-modeling.md b/evaluations/threat-modeling.md index dd35034..80c59eb 100644 --- a/evaluations/threat-modeling.md +++ b/evaluations/threat-modeling.md @@ -15,13 +15,15 @@ Anyone is invited to contribute to this document, as it is a [collective effort] ## Analysis -| Category | Threat | Description | Impact | Mitigation | -|-----------|--------------------------|-----------------------------------------------------------------------------|----------------------------------|-------------------------------------------------------------| -| Spoofing | Phishing-Induced Spoofing| Exploits the private key loaded directly into the app via phishing to send unwanted requests. | Draining the user's wallet funds, store unwanted content. | Use cold wallet. | -| | Same-Chain Replay | Reuses a signed request on the same chain to spoof user actions. | Drained wallet funds. | Include a unique nonce in request data. | -| | Cross-Chain Replay | Replays a signed request on another chain. | Drained wallet funds. | Implement EIP-712. | -| | Client Spoofing via API | Access to the exposed node to use the API. | Node full access. | Educate users. - | +| Category | Threat | Description | Impact | Mitigation | +| --------- | -------------------------------- | --------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | ------------------------------------------------ | +| Spoofing | Phishing-Induced Spoofing | Exploits the private key loaded directly into the app via phishing to send unwanted requests. | Draining the user's wallet funds, store unwanted content. | Use cold wallet. | +| Spoofing | Same-Chain Replay | Reuses a signed transaction on the same chain to spoof user actions. | Drained wallet funds. | Include a unique nonce in request data. | +| Spoofing | Cross-Chain Replay | Replays a signed transaction on another chain. | Drained wallet funds. | Implement EIP-712. | +| Spoofing | Client Spoofing via API | Access to the exposed node to use the API. | Node full access. | Educate users. | +| Tempering | Fake proofs | The storage provider sends fake proofs. | Contracts reward without actual data storage, reducing network reliability. | Require random challenges periodically. | +| Tempering | `markProofAsMissing` re-entrancy | The validator uses re-entrancy to slash multiple times. | Excessive collateral slashing of the host, proof validation failure. | Apply the `Checks-Effects-Interactions` pattern. | + ## Spoofing ### Phishing-Induced Spoofing @@ -31,63 +33,63 @@ Anyone is invited to contribute to this document, as it is a [collective effort] When starting a Codex node, the user must load his private key to pay for initiating new storage requests. This private key is loaded into memory, and there is no authentication process to use the REST API. An attacker could reach the user via email phishing, pretending to be from Codex. The email might redirect to a malicious website or include a form that, upon the user's click, triggers a request to the Codex node to create a new storage request. ``` - ────── - ─│ ─│ ┌────────────────┐ -│ │ │ │ -│ Attacker │───────────▶│ Email phishing │ -│ │ │ │ - ─│ ─│ └────────────────┘ - ────── │ - • │ - • │ - • ▼ - • ────── - • ─│ ─│ - • │ │ - • │ User │ - • │ │ - • ─│ ─│ - • ────── - • │ - • │ - • │ Clicks on the phishing email - • │ - • │ - • ▼ - • ┌────────────────┐ - • │ │ - • │ Unsecure form │ - • │ │ - • └────────────────┘ - • │ - • │ Submits the form - • │ - • │ action=/storage/request/CIDMalicious method=POST + ────── + ─│ ─│ ┌────────────────┐ +│ │ │ │ +│ Attacker │───────────▶│ Email phishing │ +│ │ │ │ + ─│ ─│ └────────────────┘ + ────── │ + • │ + • │ + • ▼ + • ────── + • ─│ ─│ + • │ │ + • │ User │ + • │ │ + • ─│ ─│ + • ────── + • │ + • │ + • │ Clicks on the phishing email + • │ + • │ + • ▼ + • ┌────────────────┐ + • │ │ + • │ Unsecure form │ + • │ │ + • └────────────────┘ + • │ + • │ Submits the form + • │ + • │ action=/storage/request/CIDMalicious method=POST • │ input name="pricePerBytePerSecond" value="100000" - • ▼ - • ┌────────────────┐ - • │ │ - • │ Codex node │ - • │ │ - • └────────────────┘ - • │ - • │ POST /storage/request/CIDMalicious - • │ pricePerBytePerSecond: 1000000 - • │ - • ▼ - • ┌────────────────┐ - • │ │ - •••••••••••••••••••│ Contract done │ - │ │ - └────────────────┘ + • ▼ + • ┌────────────────┐ + • │ │ + • │ Codex node │ + • │ │ + • └────────────────┘ + • │ + • │ POST /storage/request/CIDMalicious + • │ pricePerBytePerSecond: 1000000 + • │ + • ▼ + • ┌────────────────┐ + • │ │ + •••••••••••••••••••│ Contract done │ + │ │ + └────────────────┘ ``` -Edit/view: https://cascii.app/437bc - +Edit/view: https://cascii.app/437bc #### Impacts This could lead to two issues: + - **Financial Loss**: Malicious requests drain user wallet funds - **Unwanted Content**: Attackers force storage of insecure or illegal files via malicious CIDs, risking legal or reputational harm. @@ -105,54 +107,56 @@ While this strategy mitigates the financial impact of unwanted storage requests, #### Scenario -An attacker reuses a user’s signed `StorageRequest` on the same chain to spoof additional requests, attempting to drain funds. +An attacker reuses a user’s signed transaction on the same chain to spoof additional requests, attempting to drain funds. ``` - ────── - ─│── ───│ - │ │ - │ │ - │ User │ - │ │ - │ │ - ─│── ───│ - ────── - │ - │ - │ - │ Storage request - │ - │ - │ - ▼ -┌──────────────────────┐ -│ │ -│ Codex node │ -│ │ -└──────────────────────┘ - │ - │ - │ - ▼ -┌──────────────────────┐ -│ │ -│ Request signature │•••••••••••• -│ │ • ────── -└──────────────────────┘ • ─│ ─│ - │ •│ │ - │ •│ Attacker │ - │ │ │ - │ ─│ ─│ - ▼ ────── -┌──────────────────────┐ │ -│ │ │ -│ Smart contract │ ◀────────────────┘ -│ │ -└──────────────────────┘ + ────── + ─│── ───│ + │ │ + │ │ + │ User │ + │ │ + │ │ + ─│── ───│ + ────── + │ + │ + │ + │ Storage request + │ + │ + │ + ▼ +┌──────────────────────┐ +│ │ +│ Codex node │ +│ │ +└──────────────────────┘ + │ + │ + │ + ▼ +┌──────────────────────┐ +│ │ +│ Request signature │•••••••••••••• +│ │ • +└──────────────────────┘ • + │ • + │ ────── + │ ─│ ─│ + │ │ │ + │ │ Attacker │ + │ │ │ + │ ─│ ─│ + ▼ ────── +┌──────────────────────┐ │ +│ │ │ +│ Smart contract │◀────────────┘ +│ │ +└──────────────────────┘ ``` -Edit/view: https://cascii.app/8edc1 - +Edit/view: https://cascii.app/3577b #### Impacts @@ -166,55 +170,55 @@ Include a unique, random `nonce` in the request data. This ensures signatures ar #### Scenario -An attacker captures a user’s signed `StorageRequest` from one chain and replays it on another with an identical `Marketplace.sol` contract. The signature, publicly visible in blockchain, validates without needing the user’s private key, spoofing their intent. +An attacker captures a user’s signed transaction from one chain and replays it on another with an identical `Marketplace.sol` contract. The signature, publicly visible in blockchain, validates without needing the user’s private key, spoofing their intent. ``` - ────── - ─│── ───│ - │ │ - │ │ - │ User │ - │ │ - │ │ - ─│── ───│ - ────── - │ - │ - │ - │ Storage request - │ - │ - │ - ▼ -┌──────────────────────┐ -│ │ -│ Codex node │ -│ │ -└──────────────────────┘ - │ - │ - │ - ▼ -┌──────────────────────┐ -│ │ -│ Request signature │ -│ │ -└──────────────────────┘ - │ - │ - │ - │ - ▼ -┌──────────────────────┐ -│ │ -│ Smart contract │ ────── -│ │ ─│ ─│ -└──────────────────────┘ │ │ - │ ••••••••••│ Attacker │─────── - │ • │ │ │ - │ • ─│ ─│ │ - │ • ────── │ - │ • │ + ────── + ─│── ───│ + │ │ + │ │ + │ User │ + │ │ + │ │ + ─│── ───│ + ────── + │ + │ + │ + │ Storage request + │ + │ + │ + ▼ +┌──────────────────────┐ +│ │ +│ Codex node │ +│ │ +└──────────────────────┘ + │ + │ + │ + ▼ +┌──────────────────────┐ +│ │ +│ Request signature │ +│ │ +└──────────────────────┘ + │ + │ + │ + │ + ▼ +┌──────────────────────┐ +│ │ +│ Smart contract │ ────── +│ │ ─│ ─│ +└──────────────────────┘ │ │ + │ ••••••••••│ Attacker │─────── + │ • │ │ │ + │ • ─│ ─│ │ + │ • ────── │ + ▼ • │ ┌──────────────────────┐ • │ ┌──────────────────────┐ │ │ • │ │ │ │ Chain 1001 │••••••••••• └───────│ Chain 1002 │ @@ -227,11 +231,11 @@ Edit/view: https://cascii.app/d312b #### Impacts -- **Financial Loss**: Replayed requests on another chain drain user funds +- **Financial Loss**: Replayed requests on another chain drain user funds #### Mitigation -Implement EIP-712 to include chain-specific data in signed storage requests, ensuring signatures are valid only on the intended chain and preventing unauthorized replays on other chains. +Implement EIP-712 to include chain-specific data in signed transaction, ensuring signatures are valid only on the intended chain and preventing unauthorized replays on other chains. ### Client Spoofing via API @@ -240,41 +244,40 @@ Implement EIP-712 to include chain-specific data in signed storage requests, ens A user starts a node locally and uses `api-bindaddr` with the value `0.0.0.0`. Worse, he confuses port forwarding and enable it for the REST API as well. ``` - ────── - ─│── ───│ - │ │ - │ │ - ││ User │──────────────────┐ - ││ │ │ - │ │ │ │ - │ ─│── ───│ │ - Starts with 0:0:0:0 │ ────── │ Enables port forwarding for REST api - │ │ - ┌───────────────────┘ │ - │ │ - │ │ - │ │ - │ │ - ▼ ▼ - ┌──────────────────────┐ ┌──────────────────────┐ - │ │ │ │ - │ Codex node │ │ Codex node │ - │ │ │ │ - └──────────────────────┘ └──────────────────────┘ - ▲ ▲ - │ │ - │ │ - ────── │ │ ────── - ─│ ─│ │ │ ─│ ─│ -│ Attacker │ │ │ │ │ -│ on same │────────────┘ └─────────────────│ Attacker │ -│ network │ │ │ - ─│ ─│ ─│ ─│ - ────── ────── - + ────── + ─│── ───│ + │ │ + │ │ + ┌────────────────────│ User │──────────────────┐ + │ │ │ │ + │ │ │ │ + │ ─│── ───│ │ + │ ────── │ + │ │ + │ Starts with 0:0:0:0 │ Enables port forwarding for REST api + │ │ + │ │ + │ │ + │ │ + ▼ ▼ + ┌──────────────────────┐ ┌──────────────────────┐ + │ │ │ │ + │ Codex node │ │ Codex node │ + │ │ │ │ + └──────────────────────┘ └──────────────────────┘ + ▲ ▲ + │ │ + │ │ + ────── │ │ ────── + ─│ ─│ │ │ ─│ ─│ +│ Attacker │ │ │ │ │ +│ on same │────────────┘ └─────────────────│ Attacker │ +│ network │ │ │ + ─│ ─│ ─│ ─│ + ────── ────── ``` -Edit/view: https://cascii.app/1cca0 +Edit/view: https://cascii.app/28692 #### Impacts @@ -284,5 +287,134 @@ Edit/view: https://cascii.app/1cca0 Educate the user to not use `0.0.0.0` for `api-bindaddr` unless he really knows what he is doing and not enabling the port forwarding for the REST API. A warning during the startup could be displayed if `api-bindaddr` is not bound to localhost. -[1]: https://owasp.org/www-community/Threat_Modeling_Process#stride -[2]: https://cdn2.hubspot.net/hubfs/4598121/Content%20PDFs/VerSprite-PASTA-Threat-Modeling-Process-for-Attack-Simulation-Threat-Analysis.pdf \ No newline at end of file +## Tempering + +### Fake proofs + +#### Scenario + +After the Codex contract starts, a storage provider stops storing the data and attempts to send fake proofs, claiming they are still hosting the content, using initial data received. + +``` + ────── + ─│ ─│ + │ │ + │ User │ + │ │ + ─│ ─│ + ────── + │ + Storage │ + Request │ + │ + ▼ +┌────────────────────────┐ +│ │ +│ Codex network │──────────────┐ +│ │ │ +└────────────────────────┘ │ + │ │ + │ │ + │ Delete the file │ + │ Submit fake proof │ + │ │ + │ │ + │ │ + │ ────── + │ ─│ ─│ + │ │ Storage │ + │ │ Provider │ + │ │ │ + │ ─│ ─│ + │ ────── + │ ▲ + │ • + │ • + │ • + │ • + │ • + │ • + ▼ • + ┌────────────────────┐ • + │Slot 1│Slot 2│Slot 3│•••••••••••••••••• + └────────────────────┘ +``` + +Edit/view: https://cascii.app/629b5 + +#### Impacts + +- **Financial**: Attackers attempt to earn contract rewards at the end of the contract without storing the file. +- **Availability**: The file becomes unavailable from that storage provider, reducing network reliability. + +#### Mitigation + +Codex issues periodic random challenges based on blockchain randomness to verify that storage providers hold the data. Each failed challenge slashes the provider’s collateral. After multiple failed proofs, the provider is removed from the contract, freeing the slot for another provider. + +### markProofAsMissing re-entrency + +#### Scenario + +A validator could exploit a reentrancy vulnerability in `markProofAsMissing` by re-entering the function during an external token transfer, allowing multiple slashes and rewards for a single missed proof within one transaction. + +```js +// Generated from slither report +Reentrancy in Marketplace.markProofAsMissing(SlotId,Periods.Period) (contracts/Marketplace.sol#338-360): + External calls: + - assert(bool)(_token.transfer(msg.sender,validatorRewardAmount)) (contracts/Marketplace.sol#352) + Event emitted after the call(s): + - RequestFailed(requestId) (contracts/Marketplace.sol#396) + - _forciblyFreeSlot(slotId) (contracts/Marketplace.sol#358) + - SlotFreed(requestId,slot.slotIndex) (contracts/Marketplace.sol#385) + - _forciblyFreeSlot(slotId) (contracts/Marketplace.sol#358) +``` + +``` + ────── + ─│ ─│ + │ │ + │ User │ + │ │ + ─│ ─│ + ────── + │ + Storage │ + Request │ + ▼ + ┌───────────────────────────┐ +Re-entrency │ │ + │ │ + ┌╶╶╶╶╶╶╶╶╶╶▶│ Codex network │ + ╷ │ │ + ╷ │ │ + ╷ ▲───────────────────────────┘ + ╷ ╷ │ + ╷ ╷ │ + ────── ╷ │ ────── + ─│ ─│ ╷ │ ─│ ─│ + │ │ ╷ │ │ │ + │ Validator │╶╶╶╶╶┘ │ │ SP │ + │ │ │ │ │ + ─│ ─│ │ ─│ ─│ + ────── │ ────── + │ │ ▲ + │ ▼ • + │ ┌────────────────────┐ • + └──────────────│Slot 1│Slot 2│Slot 3│••••••••••••••• + └────────────────────┘ +``` + +Edit/view: https://cascii.app/5ead7 + +#### Impacts + +- **Financial**: Attackers could earn multiple validation rewards and excessively slash the host’s collateral for a single missed proof, draining funds unfairly. +- **Validation**: Repeated slashing disrupts PoR verification, potentially marking valid proofs as missing and undermining trust. + +#### Mitigation + +Apply the `Checks-Effects-Interactions` pattern by updating state before the external `_token.transfer` call. +Use OpenZeppelin’s `ReentrancyGuard` to block reentrant calls. + +[1]: https://owasp.org/www-community/Threat_Modeling_Process#stride +[2]: https://cdn2.hubspot.net/hubfs/4598121/Content%20PDFs/VerSprite-PASTA-Threat-Modeling-Process-for-Attack-Simulation-Threat-Analysis.pdf From 4d56a52ed448ba204487315f0dbb4269f691d5a2 Mon Sep 17 00:00:00 2001 From: Arnaud Date: Wed, 16 Apr 2025 17:51:32 +0200 Subject: [PATCH 03/14] Add repudiation threats --- evaluations/threat-modeling.md | 127 ++++++++++++++++++++++++++++++--- 1 file changed, 119 insertions(+), 8 deletions(-) diff --git a/evaluations/threat-modeling.md b/evaluations/threat-modeling.md index 80c59eb..b9372c0 100644 --- a/evaluations/threat-modeling.md +++ b/evaluations/threat-modeling.md @@ -15,17 +15,21 @@ Anyone is invited to contribute to this document, as it is a [collective effort] ## Analysis -| Category | Threat | Description | Impact | Mitigation | -| --------- | -------------------------------- | --------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | ------------------------------------------------ | -| Spoofing | Phishing-Induced Spoofing | Exploits the private key loaded directly into the app via phishing to send unwanted requests. | Draining the user's wallet funds, store unwanted content. | Use cold wallet. | -| Spoofing | Same-Chain Replay | Reuses a signed transaction on the same chain to spoof user actions. | Drained wallet funds. | Include a unique nonce in request data. | -| Spoofing | Cross-Chain Replay | Replays a signed transaction on another chain. | Drained wallet funds. | Implement EIP-712. | -| Spoofing | Client Spoofing via API | Access to the exposed node to use the API. | Node full access. | Educate users. | -| Tempering | Fake proofs | The storage provider sends fake proofs. | Contracts reward without actual data storage, reducing network reliability. | Require random challenges periodically. | -| Tempering | `markProofAsMissing` re-entrancy | The validator uses re-entrancy to slash multiple times. | Excessive collateral slashing of the host, proof validation failure. | Apply the `Checks-Effects-Interactions` pattern. | +| Category | Threat | Description | Impact | Mitigation | +| ----------- | -------------------------------- | --------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | ------------------------------------------------ | +| Spoofing | Phishing-Induced Spoofing | Exploits the private key loaded directly into the app via phishing to send unwanted requests. | Draining the user's wallet funds, store unwanted content. | Use cold wallet. | +| Spoofing | Same-Chain Replay | Reuses a signed transaction on the same chain to spoof user actions. | Drained wallet funds. | Include a unique nonce in request data. | +| Spoofing | Cross-Chain Replay | Replays a signed transaction on another chain. | Drained wallet funds. | Implement EIP-712. | +| Spoofing | Client Spoofing via API | Access to the exposed node to use the API. | Node full access. | Educate users. | +| Tempering | Fake proofs | The storage provider sends fake proofs. | Contracts reward without actual data storage, reducing network reliability. | Require random challenges periodically. | +| Tempering | `markProofAsMissing` re-entrancy | The validator uses re-entrancy to slash multiple times. | Excessive collateral slashing of the host, proof validation failure. | Apply the `Checks-Effects-Interactions` pattern. | +| Repudiation | Denial of File Upload | User denies uploading illegal content. | Reputation impact and trust failure | Make a clear legal statement. | +| Repudiation | Lazy Host | Service provider does not fill the slot’s content. | Reduces network reliability. | Allow multiple reservations per slot. | ## Spoofing +Threat action aimed at impersonating users or storage providers to access or manipulate files and contracts in the network. + ### Phishing-Induced Spoofing #### Scenario @@ -289,6 +293,8 @@ Educate the user to not use `0.0.0.0` for `api-bindaddr` unless he really knows ## Tempering +Threat action aimed at altering stored files, proofs, or smart contracts to disrupt the network. + ### Fake proofs #### Scenario @@ -418,3 +424,108 @@ Use OpenZeppelin’s `ReentrancyGuard` to block reentrant calls. [1]: https://owasp.org/www-community/Threat_Modeling_Process#stride [2]: https://cdn2.hubspot.net/hubfs/4598121/Content%20PDFs/VerSprite-PASTA-Threat-Modeling-Process-for-Attack-Simulation-Threat-Analysis.pdf + +## Repudiation + +Threat action aimed at denying responsibility for uploading files or agreeing to storage contracts in the network. + +### Denial of file upload + +#### Scenario + +A user uploads illegal content to Codex and later denies initiating the request, attempting to evade responsibility. + +``` + ────── + ─│ ─│ + │ │ + │ Anonymous │ + │ │ + ─│ ─│ + ────── + │ + Illegal │ + Content │ + ▼ + ┌───────────────────┐ + │ │ + │ Codex protocol │ + │ │ + └───────────────────┘ + ▲ + │ + │ + │ + ────── │ ────── + ─│ ─│ │ ─│ ─│ +│ │ │ │ │ +│ User │────────└────────│ User │ +│ │ │ │ + ─│ ─│ Download ─│ ─│ + ────── ────── +``` + +Edit/view: https://cascii.app/70aed + +#### Impacts + +- **Reputation**: Codex could be used to distribute illegal content, leading to a loss of trust in the protocol. + +#### Mitigation + +Make a clear statement that Codex is not responsible for such content and warn users of the potential risk for downloading an unknown CID. + +### Lazy Host + +#### Scenario + +A storage provider reserves a slot, but waits to fill the slot hoping a better opportunity will arise, in which the reward earned in the new opportunity would be greater than the reward earned in the original slot. + +``` + ────── ────── + ─│ ─│ ─│ ─│ + │ │ │ │ + │ User │ │ User │ + │ │ │ │ + ─│ ─│ ─│ ─│ + ────── ────── + │ ╷ + │ ╷ + │ ╷ + │ ╷ + │ ╷ + │ ┌────────────────────┐ ╷ + │ │ │ ╷ + └──────────────▶│ Codex network │◀╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶┘ + │ │ + ┌───────────└────────────────────┘╶╶╶╶╶╶╶╶╶╶╶╶┐ + │ ╷ ╷ +Request 1 │ ╷ ╷ Request 2 + │ ╷ ╷ + │ ╷ Fill Request 2 Slot 2 ╷ + ▼ ╷ ▼ + ┌────────────────────┐ ╷ ┌────────────────────┐ + │Slot 1│Slot 2│Slot 3│ ╷ │Slot 1│Slot 2│Slot 3│ + └────────────────────┘ ╷ └────────────────────┘ + │ ╷ ╷ + │ ╷ ╷ + │ ────── ╷ + │ ─│── ───│ ╷ + │ │ │ ╷ + │ │ │ ╷ + └─────────────│ Lazy host │◀╶╶╶╶╶╶╶╶╶╶╶╶╶╶┘ + │ │ +Reserve Request 1 Slot 2 │ │ Reserve Request 2 Slot 2 + ─│── ───│ + ────── +``` + +Edit/view: https://cascii.app/69a55 + +#### Impacts + +- **Availability**: The storage request will fail because the storage provider assigned to the slot decided not to fill it for a better opportunity, leaving the slot empty. + +#### Mitigation + +This attack is mitigated by allowing for multiple reservations per slot. All storage providers that have secured a reservation (capped at three) will race to fill the slot. Thus, if one or more storage providers that have reserved the slot decide to pursue other opportunities, the other storage providers that have reserved the slot will still be able to fill the slot. From 27c0ba19ea430a3ffde1e84abfa89e13bb0480c0 Mon Sep 17 00:00:00 2001 From: Arnaud Date: Wed, 16 Apr 2025 18:07:13 +0200 Subject: [PATCH 04/14] Add title anchors --- evaluations/threat-modeling.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/evaluations/threat-modeling.md b/evaluations/threat-modeling.md index b9372c0..b68c49c 100644 --- a/evaluations/threat-modeling.md +++ b/evaluations/threat-modeling.md @@ -15,22 +15,22 @@ Anyone is invited to contribute to this document, as it is a [collective effort] ## Analysis -| Category | Threat | Description | Impact | Mitigation | -| ----------- | -------------------------------- | --------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | ------------------------------------------------ | -| Spoofing | Phishing-Induced Spoofing | Exploits the private key loaded directly into the app via phishing to send unwanted requests. | Draining the user's wallet funds, store unwanted content. | Use cold wallet. | -| Spoofing | Same-Chain Replay | Reuses a signed transaction on the same chain to spoof user actions. | Drained wallet funds. | Include a unique nonce in request data. | -| Spoofing | Cross-Chain Replay | Replays a signed transaction on another chain. | Drained wallet funds. | Implement EIP-712. | -| Spoofing | Client Spoofing via API | Access to the exposed node to use the API. | Node full access. | Educate users. | -| Tempering | Fake proofs | The storage provider sends fake proofs. | Contracts reward without actual data storage, reducing network reliability. | Require random challenges periodically. | -| Tempering | `markProofAsMissing` re-entrancy | The validator uses re-entrancy to slash multiple times. | Excessive collateral slashing of the host, proof validation failure. | Apply the `Checks-Effects-Interactions` pattern. | -| Repudiation | Denial of File Upload | User denies uploading illegal content. | Reputation impact and trust failure | Make a clear legal statement. | -| Repudiation | Lazy Host | Service provider does not fill the slot’s content. | Reduces network reliability. | Allow multiple reservations per slot. | +| Category | Threat | Description | Impact | Mitigation | +| ----------- | ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | ------------------------------------------------ | +| Spoofing | [Phishing-Induced spoofing](#phishing-induced-spoofing) | Exploits the private key loaded directly into the app via phishing to send unwanted requests. | Draining the user's wallet funds, store unwanted content. | Use cold wallet. | +| Spoofing | [Same-Chain attack replays](#same-chain-attack-replays) | Reuses a signed transaction on the same chain to spoof user actions. | Drained wallet funds. | Include a unique nonce in request data. | +| Spoofing | [Cross-Chain attack replays](#cross-chain-attack-replays) | Replays a signed transaction on another chain. | Drained wallet funds. | Implement EIP-712. | +| Spoofing | [Client spoofing via API](#client-spoofing-via-api) | Access to the exposed node to use the API. | Node full access. | Educate users. | +| Tempering | [Fake proofs](#fake-proofs) | The storage provider sends fake proofs. | Contracts reward without actual data storage, reducing network reliability. | Require random challenges periodically. | +| Tempering | [markProofAsMissing re-entrency](#markproofasmissing-re-entrency) | The validator uses re-entrancy to slash multiple times. | Excessive collateral slashing of the host, proof validation failure. | Apply the `Checks-Effects-Interactions` pattern. | +| Repudiation | [Denial of file upload](#denial-of-file-upload) | User denies uploading illegal content. | Reputation impact and trust failure | Make a clear legal statement. | +| Repudiation | [Lazy host](#lazy-host) | Service provider does not fill the slot’s content. | Reduces network reliability. | Allow multiple reservations per slot. | ## Spoofing Threat action aimed at impersonating users or storage providers to access or manipulate files and contracts in the network. -### Phishing-Induced Spoofing +### Phishing-Induced spoofing #### Scenario @@ -170,7 +170,7 @@ Edit/view: https://cascii.app/3577b Include a unique, random `nonce` in the request data. This ensures signatures are unique per request, preventing reuse on the same chain. Codex’s current implementation includes this, fully mitigating the threat. -### Cross-Chain Replay +### Cross-Chain attack replays #### Scenario @@ -241,7 +241,7 @@ Edit/view: https://cascii.app/d312b Implement EIP-712 to include chain-specific data in signed transaction, ensuring signatures are valid only on the intended chain and preventing unauthorized replays on other chains. -### Client Spoofing via API +### Client spoofing via API #### Scenario @@ -475,7 +475,7 @@ Edit/view: https://cascii.app/70aed Make a clear statement that Codex is not responsible for such content and warn users of the potential risk for downloading an unknown CID. -### Lazy Host +### Lazy host #### Scenario From ec5a7fce72b7fddc48ba7731a3991fc78619beb2 Mon Sep 17 00:00:00 2001 From: Arnaud Date: Wed, 16 Apr 2025 18:11:46 +0200 Subject: [PATCH 05/14] Fix description --- evaluations/threat-modeling.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/evaluations/threat-modeling.md b/evaluations/threat-modeling.md index b68c49c..8e0f7fc 100644 --- a/evaluations/threat-modeling.md +++ b/evaluations/threat-modeling.md @@ -24,7 +24,7 @@ Anyone is invited to contribute to this document, as it is a [collective effort] | Tempering | [Fake proofs](#fake-proofs) | The storage provider sends fake proofs. | Contracts reward without actual data storage, reducing network reliability. | Require random challenges periodically. | | Tempering | [markProofAsMissing re-entrency](#markproofasmissing-re-entrency) | The validator uses re-entrancy to slash multiple times. | Excessive collateral slashing of the host, proof validation failure. | Apply the `Checks-Effects-Interactions` pattern. | | Repudiation | [Denial of file upload](#denial-of-file-upload) | User denies uploading illegal content. | Reputation impact and trust failure | Make a clear legal statement. | -| Repudiation | [Lazy host](#lazy-host) | Service provider does not fill the slot’s content. | Reduces network reliability. | Allow multiple reservations per slot. | +| Repudiation | [Lazy host](#lazy-host) | Service provider does not fill the slot. | Reduces network reliability. | Allow multiple reservations per slot. | ## Spoofing From 969e91a8b21b74e2aeb1ce69af491a356bc8309a Mon Sep 17 00:00:00 2001 From: Arnaud Date: Thu, 17 Apr 2025 09:19:58 +0200 Subject: [PATCH 06/14] Add information disclosure threat --- evaluations/threat-modeling.md | 158 ++++++++++++++++++++++++++++++--- 1 file changed, 147 insertions(+), 11 deletions(-) diff --git a/evaluations/threat-modeling.md b/evaluations/threat-modeling.md index 8e0f7fc..35ee98c 100644 --- a/evaluations/threat-modeling.md +++ b/evaluations/threat-modeling.md @@ -15,16 +15,17 @@ Anyone is invited to contribute to this document, as it is a [collective effort] ## Analysis -| Category | Threat | Description | Impact | Mitigation | -| ----------- | ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | ------------------------------------------------ | -| Spoofing | [Phishing-Induced spoofing](#phishing-induced-spoofing) | Exploits the private key loaded directly into the app via phishing to send unwanted requests. | Draining the user's wallet funds, store unwanted content. | Use cold wallet. | -| Spoofing | [Same-Chain attack replays](#same-chain-attack-replays) | Reuses a signed transaction on the same chain to spoof user actions. | Drained wallet funds. | Include a unique nonce in request data. | -| Spoofing | [Cross-Chain attack replays](#cross-chain-attack-replays) | Replays a signed transaction on another chain. | Drained wallet funds. | Implement EIP-712. | -| Spoofing | [Client spoofing via API](#client-spoofing-via-api) | Access to the exposed node to use the API. | Node full access. | Educate users. | -| Tempering | [Fake proofs](#fake-proofs) | The storage provider sends fake proofs. | Contracts reward without actual data storage, reducing network reliability. | Require random challenges periodically. | -| Tempering | [markProofAsMissing re-entrency](#markproofasmissing-re-entrency) | The validator uses re-entrancy to slash multiple times. | Excessive collateral slashing of the host, proof validation failure. | Apply the `Checks-Effects-Interactions` pattern. | -| Repudiation | [Denial of file upload](#denial-of-file-upload) | User denies uploading illegal content. | Reputation impact and trust failure | Make a clear legal statement. | -| Repudiation | [Lazy host](#lazy-host) | Service provider does not fill the slot. | Reduces network reliability. | Allow multiple reservations per slot. | +| Category | Threat | Description | Impact | Mitigation | +| ---------------------- | ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | ------------------------------------------------ | +| Spoofing | [Phishing-Induced spoofing](#phishing-induced-spoofing) | Exploits the private key loaded directly into the app via phishing to send unwanted requests. | Draining the user's wallet funds, store unwanted content. | Use cold wallet. | +| Spoofing | [Same-Chain attack replays](#same-chain-attack-replays) | Reuses a signed transaction on the same chain to spoof user actions. | Drained wallet funds. | Include a unique nonce in request data. | +| Spoofing | [Cross-Chain attack replays](#cross-chain-attack-replays) | Replays a signed transaction on another chain. | Drained wallet funds. | Implement EIP-712. | +| Spoofing | [Client spoofing via API](#client-spoofing-via-api) | Access to the exposed node to use the API. | Node full access. | Educate users. | +| Tempering | [Fake proofs](#fake-proofs) | The storage provider sends fake proofs. | Contracts reward without actual data storage, reducing network reliability. | Require random challenges periodically. | +| Tempering | [markProofAsMissing re-entrency](#markproofasmissing-re-entrency) | The validator uses re-entrancy to slash multiple times. | Excessive collateral slashing of the host, proof validation failure. | Apply the `Checks-Effects-Interactions` pattern. | +| Repudiation | [Denial of file upload](#denial-of-file-upload) | User denies uploading illegal content. | Reputation impact and trust failure | Make a clear legal statement. | +| Repudiation | [Clever host](#clever-host) | Storage provider abandon its duties for a better opportunity. | Reduces network reliability. | Slash collateral and reward repairing slot. | +| Information disclosure | [Uploaded files exposed](#uploaded-files-exposed) | Non encrypted files can be reconstructed. | Reputation and privacy exposure. | Add encryption layer. | ## Spoofing @@ -351,7 +352,7 @@ Edit/view: https://cascii.app/629b5 #### Impacts - **Financial**: Attackers attempt to earn contract rewards at the end of the contract without storing the file. -- **Availability**: The file becomes unavailable from that storage provider, reducing network reliability. +- **Availability**: The slot becomes unavailable from that storage provider, reducing network reliability. #### Mitigation @@ -475,6 +476,141 @@ Edit/view: https://cascii.app/70aed Make a clear statement that Codex is not responsible for such content and warn users of the potential risk for downloading an unknown CID. +### Clever host + +#### Scenario + +In this attack, an SP could fill a slot, and while fulfilling its duties, see +that a better opportunity has arisen, and abandon its duties in the first slot +to fill the second slot. + +``` + ────── + ─│ ─│ + │ │ + │ User │ + │ │ + ─│ ─│ ────── + ────── ─│ ─│ + │ │Better │ + │ │Opportunity│ + │ │ │ + │ ─│ ─│ + │ ────── + ┌────────────────────┐ │ + │ │ │ + │ Codex network │◀──────────────────┘ + │ │ + └─────────────────────────────────────────────┐ + │ │ + Request 1 │ │ + │ │ + │ │ + ▼ │ + ┌────────────────────┐ │ + │Slot 1│Slot 2│Slot 3│ │ + └────────────────────┘ │ + ▲ │ + │ │ +Fill Request 1 Slot 2 │ │ + │ │ + ────── Abandon Request 1 Slot 2 │ + ─│── ───│ to fill Request 2 Slot 2 │ + │ │ ▼ + │ │ ┌────────────────────┐ + │ Clever host │────────────────│Slot 1│Slot 2│Slot 3│ + │ │ └────────────────────┘ + │ │ + ─│── ───│ + ────── +``` + +Edit/view: https://cascii.app/267a1 + +#### Impacts + +- **Availability**: The slot becomes unavailable from that storage provider, reducing network reliability. + +#### Mitigation + +This attack is mitigated by the storage provider losing its request collateral for the first +slot once it is abandoned. Additionally, once the storage provider fills the first slot, it +will accrue rewards over time that will not be paid out until the request +successfully completes. These rewards act as another disincentive for the storage +provider to abandon the slot. + +## Information disclosure + +Information disclosure occurs when private or sensitive information such as user data, file contents, or system secrets is unintentionally or maliciously revealed to unauthorized parties. + +### Uploaded files exposed + +#### Scenario + +A user uploads a confidential file to Codex. Storage providers store encrypted slots of the file. Without encryption, storage providers could agree to gather slots and reassemble the full content. + +``` + ────── + ─│ ─│ + │ │ + │ User │ + │ │ + ─│ ─│ + ────── + │ + │ + │ + │ + ▼ + ┌────────────────────┐ + │ │ + │ Codex network │ + │ │ + └────────────────────┘ + │ + │ + │ + │ + ▼ + ┌────────────────────┐ + ┌────────────▶│Slot 1│Slot 2│Slot 3│◀─────────────┐ + │ └────────────────────┘ │ + │ ▲ │ + │ │ │ + │ │ │ + │ │ │ + ────── ────── ────── + ─│── ───│ ─│── ───│ ─│── ───│ + │ │ │ │ │ │ +│ │ │ │ │ │ +│ SP 2 │ │ SP 1 │ │ SP 3 │ +│ │ │ │ │ │ + │ │ │ │ │ │ + ─│── ───│ ─│── ───│ ─│── ───│ + ────── ────── ────── + │ │ │ + │ │ │ + │ ▼ │ + │ ┌──────────────────────┐ │ + │ │ │ │ + └────────────▶│ Original file │◀───────────┘ + │ │ + └──────────────────────┘ +``` + +Edit/view: https://cascii.app/3213e + +#### Impacts + +- **Reputation**: Codex cannot guarantee confidentiality, leading to a loss of trust in the protocol. +- **Privacy**: Exposure of sensitive user data could violate privacy, potentially resulting in legal or regulatory consequences. + +#### Mitigation + +Implement encryption to ensure that only authorized users can decrypt and access the file contents. + +## Denial of service + ### Lazy host #### Scenario From 12497badb0b05e419f2f494b0656d4016782d64d Mon Sep 17 00:00:00 2001 From: Arnaud Date: Thu, 17 Apr 2025 09:54:44 +0200 Subject: [PATCH 07/14] Update schema --- evaluations/threat-modeling.md | 477 ++++++++++++++++----------------- 1 file changed, 237 insertions(+), 240 deletions(-) diff --git a/evaluations/threat-modeling.md b/evaluations/threat-modeling.md index 35ee98c..459d30e 100644 --- a/evaluations/threat-modeling.md +++ b/evaluations/threat-modeling.md @@ -124,44 +124,46 @@ An attacker reuses a user’s signed transaction on the same chain to spoof addi │ │ ─│── ───│ ────── - │ - │ - │ - │ Storage request - │ - │ - │ + ╷ + ╷ + ╷ + ╷ Storage request + ╷ + ╷ + ╷ ▼ ┌──────────────────────┐ │ │ │ Codex node │ │ │ └──────────────────────┘ - │ - │ - │ + ╷ + ╷ + ╷ ▼ ┌──────────────────────┐ │ │ -│ Request signature │•••••••••••••• -│ │ • -└──────────────────────┘ • - │ • - │ ────── - │ ─│ ─│ - │ │ │ - │ │ Attacker │ - │ │ │ - │ ─│ ─│ - ▼ ────── -┌──────────────────────┐ │ -│ │ │ -│ Smart contract │◀────────────┘ +│ Request signature │╶╶╶╶╶╶╶╶╶╶╶╶╶┐ +│ │ ╷ +└──────────────────────┘ ╷ + ╷ ╷ + ╷ ▼ + ╷ ────── + ╷ ─│ ─│ + ╷ │ │ + ╷ │ Attacker │ + ╷ │ │ + ╷ ─│ ─│ + ╷ ────── + ▼ ╷ +┌──────────────────────┐ ╷ +│ │ ╷ +│ Smart contract │◀╶╶╶╶╶╶╶╶╶╶╶╶┘ │ │ └──────────────────────┘ ``` -Edit/view: https://cascii.app/3577b +Edit/view: https://cascii.app/b28b7 #### Impacts @@ -187,52 +189,52 @@ An attacker captures a user’s signed transaction from one chain and replays it │ │ ─│── ───│ ────── - │ - │ - │ - │ Storage request - │ - │ - │ + ╷ + ╷ + ╷ + ╷ Storage request + ╷ + ╷ + ╷ ▼ ┌──────────────────────┐ │ │ │ Codex node │ │ │ └──────────────────────┘ - │ - │ - │ + ╷ + ╷ + ╷ ▼ ┌──────────────────────┐ │ │ │ Request signature │ │ │ └──────────────────────┘ - │ - │ - │ - │ + ╷ + ╷ + ╷ + ╷ ▼ -┌──────────────────────┐ -│ │ -│ Smart contract │ ────── -│ │ ─│ ─│ -└──────────────────────┘ │ │ - │ ••••••••••│ Attacker │─────── - │ • │ │ │ - │ • ─│ ─│ │ - │ • ────── │ - ▼ • │ -┌──────────────────────┐ • │ ┌──────────────────────┐ -│ │ • │ │ │ -│ Chain 1001 │••••••••••• └───────│ Chain 1002 │ -│ │ │ │ -└──────────────────────┘ └──────────────────────┘ - +┌──────────────────────┐ ┌──────────────────────┐ +│ │ │ │ +│ Smart contract │ │ Chain 1002 │ +│ │ │ │ +└──────────────────────┘ └──────────────────────┘ + ╷ ▲ + ╷ ╷ + ╷ ╷ + ╷ ╷ + ▼ ────── +┌──────────────────────┐ ─│ ─│ +│ │ │ │ +│ Chain 1001 │◀╶╶╶╶╶╶╶╶╶╶╶╶╶╶│ Attacker │ +│ │ │ │ +└──────────────────────┘ ─│ ─│ + ────── ``` -Edit/view: https://cascii.app/d312b +Edit/view: https://cascii.app/9951e #### Impacts @@ -249,40 +251,43 @@ Implement EIP-712 to include chain-specific data in signed transaction, ensuring A user starts a node locally and uses `api-bindaddr` with the value `0.0.0.0`. Worse, he confuses port forwarding and enable it for the REST API as well. ``` - ────── - ─│── ───│ - │ │ - │ │ - ┌────────────────────│ User │──────────────────┐ - │ │ │ │ - │ │ │ │ - │ ─│── ───│ │ - │ ────── │ - │ │ - │ Starts with 0:0:0:0 │ Enables port forwarding for REST api - │ │ - │ │ - │ │ - │ │ - ▼ ▼ - ┌──────────────────────┐ ┌──────────────────────┐ - │ │ │ │ - │ Codex node │ │ Codex node │ - │ │ │ │ - └──────────────────────┘ └──────────────────────┘ - ▲ ▲ - │ │ - │ │ - ────── │ │ ────── - ─│ ─│ │ │ ─│ ─│ -│ Attacker │ │ │ │ │ -│ on same │────────────┘ └─────────────────│ Attacker │ -│ network │ │ │ - ─│ ─│ ─│ ─│ - ────── ────── + ────── + ─│── ───│ + │ │ + │ │ + ┌╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶│ User │╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶┐ + ╷ │ │ ╷ + ╷ │ │ ╷ + ╷ ─│── ───│ ╷ + ╷ ────── ╷ + ╷ ╷ + ╷ Starts with 0:0:0:0 Enables port ╷ + ╷ forwarding for ╷ + ╷ REST api ╷ + ╷ ╷ + ╷ ╷ + ▼ ▼ +┌──────────────────────┐ ┌──────────────────────┐ +│ │ │ │ +│ Codex node │ │ Codex node │ +│ │ │ │ +└──────────────────────┘ └──────────────────────┘ + ▲ ▲ + ╷ ╷ + ╷ ╷ + ╷ ╷ + ╷ ╷ + ╷ ╷ + ────── ────── + ─│ ─│ ─│ ─│ + │ Attacker │ │ │ + │ on same │ │ Attacker │ + │ network │ │ │ + ─│ ─│ ─│ ─│ + ────── ────── ``` -Edit/view: https://cascii.app/28692 +Edit/view: https://cascii.app/b762d #### Impacts @@ -310,44 +315,44 @@ After the Codex contract starts, a storage provider stops storing the data and a │ │ ─│ ─│ ────── - │ - Storage │ - Request │ - │ + ╷ + Storage ╷ + Request ╷ + ╷ ▼ ┌────────────────────────┐ │ │ -│ Codex network │──────────────┐ -│ │ │ -└────────────────────────┘ │ - │ │ - │ │ - │ Delete the file │ - │ Submit fake proof │ - │ │ - │ │ - │ │ - │ ────── - │ ─│ ─│ - │ │ Storage │ - │ │ Provider │ - │ │ │ - │ ─│ ─│ - │ ────── - │ ▲ - │ • - │ • - │ • - │ • - │ • - │ • - ▼ • - ┌────────────────────┐ • - │Slot 1│Slot 2│Slot 3│•••••••••••••••••• +│ Codex network │◀╶╶╶╶╶╶╶╶╶╶╶╶╶┐ +│ │ ╷ +└────────────────────────┘ ╷ + ╷ ╷ + ╷ ╷ + ╷ Delete the file ╷ + ╷ Submit fake proof ╷ + ╷ ╷ + ╷ ╷ + ╷ ╷ + ╷ ────── + ╷ ─│ ─│ + ╷ │ │ + ╷ │ SP │ + ╷ │ │ + ╷ ─│ ─│ + ╷ ────── + ╷ ▲ + ╷ ╷ + ╷ ╷ + ╷ ╷ + ╷ ╷ + ╷ ╷ + ╷ ╷ + ▼ ╷ + ┌────────────────────┐ ╷ + │Slot 1│Slot 2│Slot 3│╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶┘ └────────────────────┘ ``` -Edit/view: https://cascii.app/629b5 +Edit/view: https://cascii.app/9de0e #### Impacts @@ -384,9 +389,9 @@ Reentrancy in Marketplace.markProofAsMissing(SlotId,Periods.Period) (contracts/M │ │ ─│ ─│ ────── - │ - Storage │ - Request │ + ╷ + Storage ╷ + Request ╷ ▼ ┌───────────────────────────┐ Re-entrency │ │ @@ -395,23 +400,23 @@ Re-entrency │ │ ╷ │ │ ╷ │ │ ╷ ▲───────────────────────────┘ - ╷ ╷ │ - ╷ ╷ │ - ────── ╷ │ ────── - ─│ ─│ ╷ │ ─│ ─│ - │ │ ╷ │ │ │ - │ Validator │╶╶╶╶╶┘ │ │ SP │ - │ │ │ │ │ - ─│ ─│ │ ─│ ─│ - ────── │ ────── - │ │ ▲ - │ ▼ • - │ ┌────────────────────┐ • - └──────────────│Slot 1│Slot 2│Slot 3│••••••••••••••• + ╷ ╷ ╷ + ╷ ╷ ╷ + ────── ╷ ╷ ────── + ─│ ─│ ╷ ╷ ─│ ─│ + │ │ ╷ ╷ │ │ + │ Validator │╶╶╶╶╶┘ ╷ │ SP │ + │ │ ╷ │ │ + ─│ ─│ ╷ ─│ ─│ + ────── ╷ ────── + ▲ ╷ ▲ + ╷ ▼ ╷ + ╷ ┌────────────────────┐ ╷ + └╶╶╶╶╶╶╶╶╶╶╶╶╶╶│Slot 1│Slot 2│Slot 3│╶╶╶╶╶╶╶╶╶╶╶╶╶╶┘ └────────────────────┘ ``` -Edit/view: https://cascii.app/5ead7 +Edit/view: https://cascii.app/0e182 #### Impacts @@ -444,9 +449,9 @@ A user uploads illegal content to Codex and later denies initiating the request, │ │ ─│ ─│ ────── - │ - Illegal │ - Content │ + ╷ + Illegal ╷ + Content ╷ ▼ ┌───────────────────┐ │ │ @@ -454,19 +459,19 @@ A user uploads illegal content to Codex and later denies initiating the request, │ │ └───────────────────┘ ▲ - │ - │ - │ - ────── │ ────── - ─│ ─│ │ ─│ ─│ -│ │ │ │ │ -│ User │────────└────────│ User │ + ╷ + ╷ + ╷ + ────── ╷ ────── + ─│ ─│ ╷ ─│ ─│ +│ │ ╷ │ │ +│ User │╶╶╶╶╶╶╶╶└╶╶╶╶╶╶╶╶│ User │ │ │ │ │ ─│ ─│ Download ─│ ─│ ────── ────── ``` -Edit/view: https://cascii.app/70aed +Edit/view: https://cascii.app/5b9a9 #### Impacts @@ -492,30 +497,30 @@ to fill the second slot. │ │ ─│ ─│ ────── ────── ─│ ─│ - │ │Better │ - │ │Opportunity│ - │ │ │ - │ ─│ ─│ - │ ────── - ┌────────────────────┐ │ - │ │ │ - │ Codex network │◀──────────────────┘ + ╷ │Better │ + ╷ │Opportunity│ + ╷ │ │ + ╷ ─│ ─│ + ▼ ────── + ┌────────────────────┐ ╷ + │ │ ╷ + │ Codex network │◀╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶┘ │ │ - └─────────────────────────────────────────────┐ - │ │ - Request 1 │ │ - │ │ - │ │ - ▼ │ - ┌────────────────────┐ │ - │Slot 1│Slot 2│Slot 3│ │ - └────────────────────┘ │ - ▲ │ - │ │ -Fill Request 1 Slot 2 │ │ - │ │ - ────── Abandon Request 1 Slot 2 │ - ─│── ───│ to fill Request 2 Slot 2 │ + └────────────────────╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶┐ + ╷ ╷ + Request 1 ╷ ╷ + ╷ ╷ + ╷ ╷ + ▼ ╷ + ┌────────────────────┐ ╷ + │Slot 1│Slot 2│Slot 3│ ╷ + └────────────────────┘ ╷ + ▲ ╷ + ╷ ╷ +Fill Request 1 Slot 2 ╷ ╷ + ╷ ╷ + ────── Abandon Request 1 Slot 2 ╷ + ─│── ───│ to fill Request 2 Slot 2 ╷ │ │ ▼ │ │ ┌────────────────────┐ │ Clever host │────────────────│Slot 1│Slot 2│Slot 3│ @@ -525,7 +530,7 @@ Fill Request 1 Slot 2 │ │ ────── ``` -Edit/view: https://cascii.app/267a1 +Edit/view: https://cascii.app/db2da #### Impacts @@ -550,55 +555,47 @@ Information disclosure occurs when private or sensitive information such as user A user uploads a confidential file to Codex. Storage providers store encrypted slots of the file. Without encryption, storage providers could agree to gather slots and reassemble the full content. ``` - ────── - ─│ ─│ - │ │ - │ User │ - │ │ - ─│ ─│ - ────── - │ - │ - │ - │ - ▼ - ┌────────────────────┐ - │ │ - │ Codex network │ - │ │ - └────────────────────┘ - │ - │ - │ - │ - ▼ - ┌────────────────────┐ - ┌────────────▶│Slot 1│Slot 2│Slot 3│◀─────────────┐ - │ └────────────────────┘ │ - │ ▲ │ - │ │ │ - │ │ │ - │ │ │ - ────── ────── ────── - ─│── ───│ ─│── ───│ ─│── ───│ - │ │ │ │ │ │ -│ │ │ │ │ │ -│ SP 2 │ │ SP 1 │ │ SP 3 │ -│ │ │ │ │ │ - │ │ │ │ │ │ - ─│── ───│ ─│── ───│ ─│── ───│ - ────── ────── ────── - │ │ │ - │ │ │ - │ ▼ │ - │ ┌──────────────────────┐ │ - │ │ │ │ - └────────────▶│ Original file │◀───────────┘ - │ │ - └──────────────────────┘ + ────── + ─│ ─│ + │ │ + │ User │ + │ │ + ─│ ─│ ────── + ────── ─│ ─│ + ╷ │Better │ + ╷ │Opportunity│ + ╷ │ │ + ╷ ─│ ─│ + ▼ ────── + ┌────────────────────┐ ╷ + │ │ ╷ + │ Codex network │◀╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶┘ + │ │ + └────────────────────╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶┐ + ╷ ╷ + Request 1 ╷ ╷ + ╷ ╷ + ╷ ╷ + ▼ ╷ + ┌────────────────────┐ ╷ + │Slot 1│Slot 2│Slot 3│ ╷ + └────────────────────┘ ╷ + ╷ ╷ + ╷ ╷ +Fill Request 1 Slot 2 ╷ ╷ + ▼ ╷ + ────── Abandon Request 1 Slot 2 ╷ + ─│── ───│ to fill Request 2 Slot 2 ╷ + │ │ ▼ + │ │ ┌────────────────────┐ + │ Clever host │◀╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶│Slot 1│Slot 2│Slot 3│ + │ │ └────────────────────┘ + │ │ + ─│── ───│ + ────── ``` -Edit/view: https://cascii.app/3213e +Edit/view: https://cascii.app/ef5ab #### Impacts @@ -625,38 +622,38 @@ A storage provider reserves a slot, but waits to fill the slot hoping a better o │ │ │ │ ─│ ─│ ─│ ─│ ────── ────── - │ ╷ - │ ╷ - │ ╷ - │ ╷ - │ ╷ - │ ┌────────────────────┐ ╷ - │ │ │ ╷ - └──────────────▶│ Codex network │◀╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶┘ + ╷ ╷ + ╷ ╷ + ╷ ╷ + ╷ ╷ + ╷ ╷ + ╷ ┌────────────────────┐ ╷ + ╷ │ │ ╷ + └╶╶╶╶╶╶╶╶╶╶╶╶╶╶▶│ Codex network │◀╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶┘ │ │ - ┌───────────└────────────────────┘╶╶╶╶╶╶╶╶╶╶╶╶┐ - │ ╷ ╷ -Request 1 │ ╷ ╷ Request 2 - │ ╷ ╷ - │ ╷ Fill Request 2 Slot 2 ╷ + ┌╶╶╶╶╶╶╶╶╶╶╶└────────────────────┘╶╶╶╶╶╶╶╶╶╶╶╶┐ + ╷ ╷ ╷ +Request 1 ╷ ╷ ╷ Request 2 + ╷ ╷ ╷ + ╷ ╷ Fill Request 2 Slot 2 ╷ ▼ ╷ ▼ ┌────────────────────┐ ╷ ┌────────────────────┐ │Slot 1│Slot 2│Slot 3│ ╷ │Slot 1│Slot 2│Slot 3│ └────────────────────┘ ╷ └────────────────────┘ - │ ╷ ╷ - │ ╷ ╷ - │ ────── ╷ - │ ─│── ───│ ╷ - │ │ │ ╷ - │ │ │ ╷ - └─────────────│ Lazy host │◀╶╶╶╶╶╶╶╶╶╶╶╶╶╶┘ + ╷ ╷ ╷ + ╷ ╷ ╷ + ╷ ────── ╷ + ╷ ─│── ───│ ╷ + ╷ │ │ ╷ + ╷ │ │ ╷ + └╶╶╶╶╶╶╶╶╶╶╶╶▶│ Lazy host │◀╶╶╶╶╶╶╶╶╶╶╶╶╶╶┘ │ │ Reserve Request 1 Slot 2 │ │ Reserve Request 2 Slot 2 ─│── ───│ ────── ``` -Edit/view: https://cascii.app/69a55 +Edit/view: https://cascii.app/6144e #### Impacts From 168ab47e3b9008dba308a9d7f8e6e31fdff9692a Mon Sep 17 00:00:00 2001 From: Arnaud Date: Thu, 17 Apr 2025 10:02:32 +0200 Subject: [PATCH 08/14] Wrap text content --- evaluations/threat-modeling.md | 138 ++++++++++++++++++++++++--------- 1 file changed, 100 insertions(+), 38 deletions(-) diff --git a/evaluations/threat-modeling.md b/evaluations/threat-modeling.md index 459d30e..af7c2d9 100644 --- a/evaluations/threat-modeling.md +++ b/evaluations/threat-modeling.md @@ -2,16 +2,25 @@ ## Introduction -The goal of this threat modeling is to identify potential security vulnerabilities in the Codex protocol, enabling us to take actions to mitigate them. Additionally, it can serve as a starting point for directives in a security audit. The scope includes the [Nim codebase](https://github.com/codex-storage/nim-codex) and the [marketplace smart contracts](https://github.com/codex-storage/codex-contracts-eth). +The goal of this threat modeling is to identify potential security vulnerabilities in +the Codex protocol, enabling us to take actions to mitigate them. Additionally, it can +serve as a starting point for directives in a security audit. The scope includes the +[Nim codebase](https://github.com/codex-storage/nim-codex) and the +[marketplace smart contracts](https://github.com/codex-storage/codex-contracts-eth). ## Methodology -The [STRIDE][1] framework is used due to its simplicity and the ability to quickly build an analysis. -The [PASTA][2] framework was considered but is more business-oriented and suited for mature projects. Additionally, its process is heavier than STRIDE's. +The [STRIDE][1] framework is used due to its simplicity and the ability to quickly build +an analysis. +The [PASTA][2] framework was considered but is more business-oriented and suited for mature +projects. Additionally, its process is heavier than STRIDE's. -Threat modeling is an iterative process, requiring constant updates as features are added or modified in the codebase. Documenting potential security vulnerabilities helps developers to keep them in mind during the code implementation. +Threat modeling is an iterative process, requiring constant updates as features are added or +modified in the codebase. Documenting potential security vulnerabilities helps developers to +keep them in mind during the code implementation. -Anyone is invited to contribute to this document, as it is a [collective effort](https://www.threatmodelingmanifesto.org) rather than a one-person task. +Anyone is invited to contribute to this document, as it is a +[collective effort](https://www.threatmodelingmanifesto.org) rather than a one-person task. ## Analysis @@ -29,13 +38,18 @@ Anyone is invited to contribute to this document, as it is a [collective effort] ## Spoofing -Threat action aimed at impersonating users or storage providers to access or manipulate files and contracts in the network. +Threat action aimed at impersonating users or storage providers to access or manipulate +files and contracts in the network. ### Phishing-Induced spoofing #### Scenario -When starting a Codex node, the user must load his private key to pay for initiating new storage requests. This private key is loaded into memory, and there is no authentication process to use the REST API. An attacker could reach the user via email phishing, pretending to be from Codex. The email might redirect to a malicious website or include a form that, upon the user's click, triggers a request to the Codex node to create a new storage request. +When starting a Codex node, the user must load his private key to pay for initiating new +storage requests. This private key is loaded into memory, and there is no authentication +process to use the REST API. An attacker could reach the user via email phishing, +pretending to be from Codex. The email might redirect to a malicious website or include a +form that, upon the user's click, triggers a request to the Codex node to create a new storage request. ``` ────── @@ -96,23 +110,34 @@ Edit/view: https://cascii.app/437bc This could lead to two issues: - **Financial Loss**: Malicious requests drain user wallet funds -- **Unwanted Content**: Attackers force storage of insecure or illegal files via malicious CIDs, risking legal or reputational harm. +- **Unwanted Content**: Attackers force storage of insecure or illegal files via + malicious CIDs, risking legal or reputational harm. #### Mitigation -Typically, such web phishing attacks are mitigated by authentication or a [custom header](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#employing-custom-request-headers-for-ajaxapi) to verify the request’s legitimacy. +Typically, such web phishing attacks are mitigated by authentication or a +[custom header](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#employing-custom-request-headers-for-ajaxapi) to verify the request’s legitimacy. -However, Codex does not have an authentication mechanism, making options like CSRF tokens impractical and using a custom header would provide a poor user experience in Codex, as users would need to set the header manually, which is cumbersome and error-prone. +However, Codex does not have an authentication mechanism, making options like CSRF +tokens impractical and using a custom header would provide a poor user experience +in Codex, as users would need to set the header manually, which is cumbersome and error-prone. -Users can reduce the risk of significant fund drainage by employing a hot wallet with a small amount of tokens designated for storage requests, while keeping the majority of their funds in a cold wallet. This limits the exposure to phishing attacks, as only the tokens in the hot wallet are at risk. For example, a user might allocate just enough tokens to cover typical storage needs, minimizing potential losses. +Users can reduce the risk of significant fund drainage by employing a hot wallet with +a small amount of tokens designated for storage requests, while keeping the majority +of their funds in a cold wallet. This limits the exposure to phishing attacks, as only +the tokens in the hot wallet are at risk. For example, a user might allocate just enough +tokens to cover typical storage needs, minimizing potential losses. -While this strategy mitigates the financial impact of unwanted storage requests, it does not address the storage of unwanted or illegal content. An attacker could still trick the user into storing harmful files via phishing. +While this strategy mitigates the financial impact of unwanted storage requests, it does +not address the storage of unwanted or illegal content. An attacker could still trick the +user into storing harmful files via phishing. ### Same-Chain attack replays #### Scenario -An attacker reuses a user’s signed transaction on the same chain to spoof additional requests, attempting to drain funds. +An attacker reuses a user’s signed transaction on the same chain to spoof additional +requests, attempting to drain funds. ``` ────── @@ -171,13 +196,17 @@ Edit/view: https://cascii.app/b28b7 #### Mitigation -Include a unique, random `nonce` in the request data. This ensures signatures are unique per request, preventing reuse on the same chain. Codex’s current implementation includes this, fully mitigating the threat. +Include a unique, random `nonce` in the request data. This ensures signatures are unique +per request, preventing reuse on the same chain. Codex’s current implementation includes +this, fully mitigating the threat. ### Cross-Chain attack replays #### Scenario -An attacker captures a user’s signed transaction from one chain and replays it on another with an identical `Marketplace.sol` contract. The signature, publicly visible in blockchain, validates without needing the user’s private key, spoofing their intent. +An attacker captures a user’s signed transaction from one chain and replays it on another +with an identical `Marketplace.sol` contract. The signature, publicly visible in blockchain, +validates without needing the user’s private key, spoofing their intent. ``` ────── @@ -242,13 +271,16 @@ Edit/view: https://cascii.app/9951e #### Mitigation -Implement EIP-712 to include chain-specific data in signed transaction, ensuring signatures are valid only on the intended chain and preventing unauthorized replays on other chains. +Implement EIP-712 to include chain-specific data in signed transaction, ensuring +signatures are valid only on the intended chain and preventing unauthorized replays +on other chains. ### Client spoofing via API #### Scenario -A user starts a node locally and uses `api-bindaddr` with the value `0.0.0.0`. Worse, he confuses port forwarding and enable it for the REST API as well. +A user starts a node locally and uses `api-bindaddr` with the value `0.0.0.0`. +Worse, he confuses port forwarding and enable it for the REST API as well. ``` ────── @@ -291,21 +323,26 @@ Edit/view: https://cascii.app/b762d #### Impacts -- **Node full control**: Attackers can send unauthorized API requests, draining funds or storing illegal content. +- **Node full control**: Attackers can send unauthorized API requests, draining funds + or storing illegal content. #### Mitigation -Educate the user to not use `0.0.0.0` for `api-bindaddr` unless he really knows what he is doing and not enabling the port forwarding for the REST API. A warning during the startup could be displayed if `api-bindaddr` is not bound to localhost. +Educate the user to not use `0.0.0.0` for `api-bindaddr` unless he really knows what he +is doing and not enabling the port forwarding for the REST API. A warning during the +startup could be displayed if `api-bindaddr` is not bound to localhost. ## Tempering -Threat action aimed at altering stored files, proofs, or smart contracts to disrupt the network. +Threat action aimed at altering stored files, proofs, or smart contracts to disrupt +the network. ### Fake proofs #### Scenario -After the Codex contract starts, a storage provider stops storing the data and attempts to send fake proofs, claiming they are still hosting the content, using initial data received. +After the Codex contract starts, a storage provider stops storing the data and attempts +to send fake proofs, claiming they are still hosting the content, using initial data received. ``` ────── @@ -356,18 +393,25 @@ Edit/view: https://cascii.app/9de0e #### Impacts -- **Financial**: Attackers attempt to earn contract rewards at the end of the contract without storing the file. -- **Availability**: The slot becomes unavailable from that storage provider, reducing network reliability. +- **Financial**: Attackers attempt to earn contract rewards at the end of the contract + without storing the file. +- **Availability**: The slot becomes unavailable from that storage provider, reducing + network reliability. #### Mitigation -Codex issues periodic random challenges based on blockchain randomness to verify that storage providers hold the data. Each failed challenge slashes the provider’s collateral. After multiple failed proofs, the provider is removed from the contract, freeing the slot for another provider. +Codex issues periodic random challenges based on blockchain randomness to verify that +storage providers hold the data. Each failed challenge slashes the provider’s collateral. +After multiple failed proofs, the provider is removed from the contract, freeing the +slot for another provider. ### markProofAsMissing re-entrency #### Scenario -A validator could exploit a reentrancy vulnerability in `markProofAsMissing` by re-entering the function during an external token transfer, allowing multiple slashes and rewards for a single missed proof within one transaction. +A validator could exploit a reentrancy vulnerability in `markProofAsMissing` by re-entering +the function during an external token transfer, allowing multiple slashes and rewards +for a single missed proof within one transaction. ```js // Generated from slither report @@ -420,12 +464,15 @@ Edit/view: https://cascii.app/0e182 #### Impacts -- **Financial**: Attackers could earn multiple validation rewards and excessively slash the host’s collateral for a single missed proof, draining funds unfairly. -- **Validation**: Repeated slashing disrupts PoR verification, potentially marking valid proofs as missing and undermining trust. +- **Financial**: Attackers could earn multiple validation rewards and excessively + slash the host’s collateral for a single missed proof, draining funds unfairly. +- **Validation**: Repeated slashing disrupts PoR verification, potentially marking + valid proofs as missing and undermining trust. #### Mitigation -Apply the `Checks-Effects-Interactions` pattern by updating state before the external `_token.transfer` call. +Apply the `Checks-Effects-Interactions` pattern by updating state before the external +`_token.transfer` call. Use OpenZeppelin’s `ReentrancyGuard` to block reentrant calls. [1]: https://owasp.org/www-community/Threat_Modeling_Process#stride @@ -433,13 +480,15 @@ Use OpenZeppelin’s `ReentrancyGuard` to block reentrant calls. ## Repudiation -Threat action aimed at denying responsibility for uploading files or agreeing to storage contracts in the network. +Threat action aimed at denying responsibility for uploading files or agreeing to storage +contracts in the network. ### Denial of file upload #### Scenario -A user uploads illegal content to Codex and later denies initiating the request, attempting to evade responsibility. +A user uploads illegal content to Codex and later denies initiating the request, +attempting to escape responsibility. ``` ────── @@ -475,7 +524,8 @@ Edit/view: https://cascii.app/5b9a9 #### Impacts -- **Reputation**: Codex could be used to distribute illegal content, leading to a loss of trust in the protocol. +- **Reputation**: Codex could be used to distribute illegal content, leading to a + loss of trust in the protocol. #### Mitigation @@ -534,7 +584,8 @@ Edit/view: https://cascii.app/db2da #### Impacts -- **Availability**: The slot becomes unavailable from that storage provider, reducing network reliability. +- **Availability**: The slot becomes unavailable from that storage provider, + reducing network reliability. #### Mitigation @@ -546,13 +597,16 @@ provider to abandon the slot. ## Information disclosure -Information disclosure occurs when private or sensitive information such as user data, file contents, or system secrets is unintentionally or maliciously revealed to unauthorized parties. +Information disclosure occurs when private or sensitive information such as user data, +file contents, or system secrets is unintentionally or maliciously revealed to unauthorized parties. ### Uploaded files exposed #### Scenario -A user uploads a confidential file to Codex. Storage providers store encrypted slots of the file. Without encryption, storage providers could agree to gather slots and reassemble the full content. +A user uploads a confidential file to Codex. Storage providers store encrypted slots +of the file. Without encryption, storage providers could agree to gather slots and +reassemble the full content. ``` ────── @@ -599,8 +653,10 @@ Edit/view: https://cascii.app/ef5ab #### Impacts -- **Reputation**: Codex cannot guarantee confidentiality, leading to a loss of trust in the protocol. -- **Privacy**: Exposure of sensitive user data could violate privacy, potentially resulting in legal or regulatory consequences. +- **Reputation**: Codex cannot guarantee confidentiality, leading to a loss of + trust in the protocol. +- **Privacy**: Exposure of sensitive user data could violate privacy, potentially + resulting in legal or regulatory consequences. #### Mitigation @@ -612,7 +668,9 @@ Implement encryption to ensure that only authorized users can decrypt and access #### Scenario -A storage provider reserves a slot, but waits to fill the slot hoping a better opportunity will arise, in which the reward earned in the new opportunity would be greater than the reward earned in the original slot. +A storage provider reserves a slot, but waits to fill the slot hoping a better +opportunity will arise, in which the reward earned in the new opportunity would be +greater than the reward earned in the original slot. ``` ────── ────── @@ -661,4 +719,8 @@ Edit/view: https://cascii.app/6144e #### Mitigation -This attack is mitigated by allowing for multiple reservations per slot. All storage providers that have secured a reservation (capped at three) will race to fill the slot. Thus, if one or more storage providers that have reserved the slot decide to pursue other opportunities, the other storage providers that have reserved the slot will still be able to fill the slot. +This attack is mitigated by allowing for multiple reservations per slot. +All storage providers that have secured a reservation (capped at three) will race to fill the slot. +Thus, if one or more storage providers that have reserved the slot decide to +pursue other opportunities, the other storage providers that have reserved the slot will +still be able to fill the slot. From 4af732b47fb13e00ad8641073aee50907ac71daf Mon Sep 17 00:00:00 2001 From: Arnaud Date: Thu, 17 Apr 2025 11:29:07 +0200 Subject: [PATCH 09/14] Add elevation of privilege threat --- evaluations/threat-modeling.md | 69 ++++++++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+) diff --git a/evaluations/threat-modeling.md b/evaluations/threat-modeling.md index af7c2d9..090bf53 100644 --- a/evaluations/threat-modeling.md +++ b/evaluations/threat-modeling.md @@ -35,6 +35,7 @@ Anyone is invited to contribute to this document, as it is a | Repudiation | [Denial of file upload](#denial-of-file-upload) | User denies uploading illegal content. | Reputation impact and trust failure | Make a clear legal statement. | | Repudiation | [Clever host](#clever-host) | Storage provider abandon its duties for a better opportunity. | Reduces network reliability. | Slash collateral and reward repairing slot. | | Information disclosure | [Uploaded files exposed](#uploaded-files-exposed) | Non encrypted files can be reconstructed. | Reputation and privacy exposure. | Add encryption layer. | +| Elevation of privilege | [Exploring a vulnerability](#exploring-a-vulnerability) | The attacker exploits a vulnerability to take over the smart contracts. | System Disruption. | Upgradable contracts and / or admin role. | ## Spoofing @@ -724,3 +725,71 @@ All storage providers that have secured a reservation (capped at three) will rac Thus, if one or more storage providers that have reserved the slot decide to pursue other opportunities, the other storage providers that have reserved the slot will still be able to fill the slot. + +## Elevation of privilege + +Threat action intending to gain privileged access to resources in order to gain unauthorized access +to information or to compromise a system. + +### Exploring a vulnerability + +#### Scenario + +An attacker finds a vulnerability in Codex’s smart contract after it’s deployed. Anyone can call it. +The attacker uses this to change deal terms in their favor, taking control of the protocol. + +``` + ┌────────────────────────────┐ + │ │ + │ Codex │ + │ │ + └────────────────────────────┘ + ╷ + ╷ + ╷ Deploy without ownership + ╷ + ╷ + Take control of the s ▼ + mart contracts ┌───────────────────────────┐ + │ │ + ┌╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶▶│ Smart contracts │ + ╷ │ │ + ╷ ╷───────────────────────────┘ + ╷ ╷ ▲ + ╷ ╷ ╷ + ╷ ╷ ╷ + ╷ ╷ ╷ + ────── ╷ ╷ + ─│── ───│ ╷ ╷ + │ │ ╷ ╷ +│ │ ╷ ╷ +│ Attacker │◀╶╶╶╶╶╶╶┘ ╷ +│ │ ╷ + │ │ Manipulates ╷ + ─│── ───│ incoming storage ╷ + ────── requests ╷ + ╷ + ╷ + ╷ + ────── + ─│── ───│ + │ │ + │ │ + │Storage request│ + │ │ + │ │ + ─│── ───│ + ────── +``` + +Edit/view: https://cascii.app/23869 + +#### Impacts + +- **Financial Loss**: Attackers could tweak deals to steal funds or stop payments. +- **System Disruption**: The integrity of the Codex protocol is compromised, leading to a loss of trust. + +#### Mitigation + +Use upgradable contracts to allow for future fixes. Additionally, implement temporary admin roles +requiring multiple approvals for changing critical settings. From 1b4315ce526176a67d10068d2b46ec86dcbe85b0 Mon Sep 17 00:00:00 2001 From: Arnaud Date: Fri, 18 Apr 2025 16:15:51 +0200 Subject: [PATCH 10/14] Add denial of service attack --- evaluations/threat-modeling.md | 201 +++++++++++++++++++++++++++++---- 1 file changed, 180 insertions(+), 21 deletions(-) diff --git a/evaluations/threat-modeling.md b/evaluations/threat-modeling.md index 090bf53..40474ec 100644 --- a/evaluations/threat-modeling.md +++ b/evaluations/threat-modeling.md @@ -24,18 +24,25 @@ Anyone is invited to contribute to this document, as it is a ## Analysis -| Category | Threat | Description | Impact | Mitigation | -| ---------------------- | ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | ------------------------------------------------ | -| Spoofing | [Phishing-Induced spoofing](#phishing-induced-spoofing) | Exploits the private key loaded directly into the app via phishing to send unwanted requests. | Draining the user's wallet funds, store unwanted content. | Use cold wallet. | -| Spoofing | [Same-Chain attack replays](#same-chain-attack-replays) | Reuses a signed transaction on the same chain to spoof user actions. | Drained wallet funds. | Include a unique nonce in request data. | -| Spoofing | [Cross-Chain attack replays](#cross-chain-attack-replays) | Replays a signed transaction on another chain. | Drained wallet funds. | Implement EIP-712. | -| Spoofing | [Client spoofing via API](#client-spoofing-via-api) | Access to the exposed node to use the API. | Node full access. | Educate users. | -| Tempering | [Fake proofs](#fake-proofs) | The storage provider sends fake proofs. | Contracts reward without actual data storage, reducing network reliability. | Require random challenges periodically. | -| Tempering | [markProofAsMissing re-entrency](#markproofasmissing-re-entrency) | The validator uses re-entrancy to slash multiple times. | Excessive collateral slashing of the host, proof validation failure. | Apply the `Checks-Effects-Interactions` pattern. | -| Repudiation | [Denial of file upload](#denial-of-file-upload) | User denies uploading illegal content. | Reputation impact and trust failure | Make a clear legal statement. | -| Repudiation | [Clever host](#clever-host) | Storage provider abandon its duties for a better opportunity. | Reduces network reliability. | Slash collateral and reward repairing slot. | -| Information disclosure | [Uploaded files exposed](#uploaded-files-exposed) | Non encrypted files can be reconstructed. | Reputation and privacy exposure. | Add encryption layer. | -| Elevation of privilege | [Exploring a vulnerability](#exploring-a-vulnerability) | The attacker exploits a vulnerability to take over the smart contracts. | System Disruption. | Upgradable contracts and / or admin role. | +| Category | Threat | Description | Impact | Mitigation | +| ---------------------- | ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | ---------------------------------------------------------- | +| Spoofing | [Phishing-Induced spoofing](#phishing-induced-spoofing) | Exploits the private key loaded directly into the app via phishing to send unwanted requests. | Draining the user's wallet funds, store unwanted content. | Use cold wallet. | +| Spoofing | [Same-Chain attack replays](#same-chain-attack-replays) | Reuses a signed transaction on the same chain to spoof user actions. | Drained wallet funds. | Include a unique nonce in request data. | +| Spoofing | [Cross-Chain attack replays](#cross-chain-attack-replays) | Replays a signed transaction on another chain. | Drained wallet funds. | Implement EIP-712. | +| Spoofing | [Client spoofing via API](#client-spoofing-via-api) | Access to the exposed node to use the API. | Node full API access. | Educate users. | +| Tampering | [Fake proofs](#fake-proofs) | The storage provider sends fake proofs. | Contracts reward without actual data storage, reducing network reliability. | Require random challenges periodically. | +| Tampering | [markProofAsMissing re-entrency](#markproofasmissing-re-entrency) | The validator uses re-entrancy to slash multiple times. | Excessive collateral slashing of the host, proof validation failure. | Apply the `Checks-Effects-Interactions` pattern. | +| Repudiation | [Denial of file upload](#denial-of-file-upload) | User denies uploading illegal content. | Reputation impact and trust failure | Make a clear legal statement. | +| Repudiation | [Clever host](#clever-host) | Storage provider abandon its duties for a better opportunity. | Reduces network reliability. | Slash collateral and reward repairing slot. | +| Information disclosure | [Uploaded files exposed](#uploaded-files-exposed) | Non encrypted files can be reconstructed. | Reputation and privacy exposure. | Add encryption layer. | +| Elevation of privilege | [Exploring a vulnerability](#exploring-a-vulnerability) | The attacker exploits a vulnerability to take over the smart contracts. | System Disruption. | Upgradable contracts and / or admin role. | +| Denial of service | [Lazy host](#lazy-host) | Host reserves a slot, but doesn't fill it | System Disruption. | Multiple reservations. | +| Denial of service | [Lazy host](#lazy-host) | Host reserves a slot, but doesn't fill it | System Disruption. | Multiple reservations. | +| Overload attack | [Overload attack](#overload-attack) | Massive small requests to overload validators. | System Disruption. | Client doesn't release content on the network. | +| Denial of service | [Lazy Client](#lazy-client) | Starting request fees. | System Disruption. | Transaction cost | +| Denial of service | [Censoring](#censoring) | Acts like a lazy host for specific CIDs that it tries to censor fees. | System Disruption. | Dataset and CID and be rebuilt by other storage providers. | +| Denial of service | [Greedy](#greedy) | Storage provider tries to fill multiple slots in a request | System Disruption. | Expanding window mechanism | +| Denial of service | [Sticky](#sticky) | Storage provider tries to fill the same slot in a contract renewal. | System Disruption. | Expanding window mechanism | ## Spoofing @@ -48,7 +55,7 @@ files and contracts in the network. When starting a Codex node, the user must load his private key to pay for initiating new storage requests. This private key is loaded into memory, and there is no authentication -process to use the REST API. An attacker could reach the user via email phishing, +process to use the API. An attacker could reach the user via email phishing, pretending to be from Codex. The email might redirect to a malicious website or include a form that, upon the user's click, triggers a request to the Codex node to create a new storage request. @@ -324,7 +331,7 @@ Edit/view: https://cascii.app/b762d #### Impacts -- **Node full control**: Attackers can send unauthorized API requests, draining funds +- **Node full API control**: Attackers can send unauthorized API requests, draining funds or storing illegal content. #### Mitigation @@ -333,7 +340,7 @@ Educate the user to not use `0.0.0.0` for `api-bindaddr` unless he really knows is doing and not enabling the port forwarding for the REST API. A warning during the startup could be displayed if `api-bindaddr` is not bound to localhost. -## Tempering +## Tampering Threat action aimed at altering stored files, proofs, or smart contracts to disrupt the network. @@ -342,8 +349,9 @@ the network. #### Scenario -After the Codex contract starts, a storage provider stops storing the data and attempts -to send fake proofs, claiming they are still hosting the content, using initial data received. +In the case of the proof verification is weak and proofs can be submitted and verified easily, +a storage provider could stop storing the data and attempts to send fake proofs, claiming they +are still hosting the content, using initial data received. ``` ────── @@ -530,7 +538,8 @@ Edit/view: https://cascii.app/5b9a9 #### Mitigation -Make a clear statement that Codex is not responsible for such content and warn users of the potential risk for downloading an unknown CID. +Make a clear statement that Codex is not responsible for such content and warn users of the +potential risk for downloading an unknown CID. ### Clever host @@ -605,7 +614,7 @@ file contents, or system secrets is unintentionally or maliciously revealed to u #### Scenario -A user uploads a confidential file to Codex. Storage providers store encrypted slots +A user uploads a confidential file to Codex. Storage providers store non encrypted slots of the file. Without encryption, storage providers could agree to gather slots and reassemble the full content. @@ -669,6 +678,9 @@ Implement encryption to ensure that only authorized users can decrypt and access #### Scenario +In the case of a single reservation system, matching storage providers are assigned to +slot reservation by a 1-1 relation, meaning that there is one storage provider +for one reservation. A storage provider reserves a slot, but waits to fill the slot hoping a better opportunity will arise, in which the reward earned in the new opportunity would be greater than the reward earned in the original slot. @@ -716,7 +728,8 @@ Edit/view: https://cascii.app/6144e #### Impacts -- **Availability**: The storage request will fail because the storage provider assigned to the slot decided not to fill it for a better opportunity, leaving the slot empty. +- **Availability**: The storage request will fail because the storage provider assigned to the slot + decided not to fill it for a better opportunity, leaving the slot empty. #### Mitigation @@ -726,6 +739,152 @@ Thus, if one or more storage providers that have reserved the slot decide to pursue other opportunities, the other storage providers that have reserved the slot will still be able to fill the slot. +### Overload attack + +#### Scenario + +An attacker runs many small requests that generate high-volume transactions, overwhelming +validators and delaying their ability to detect missed proofs. + +``` + ────── + ─│── ───│ + │ │ + │ │ + │ Attacker │ + │ │ + │ │ + ─│── ───│ + ────── + ╷ + ╷ Small requests + ▼ + ┌─────────────────────────────────┐ + │R1│R2│R3│R4│R5│R5│R6│R7│R8│R9│R10│ + └─────────────────────────────────┘ + ╷ ╷ ╷ ╷ ╷ ╷ ╷ ╷ ╷ ╷ │ + ╷ ╷ ╷ ╷ ╷ ╷ ╷ ╷ ╷ ╷ │ + ╷ ╷ └╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶┘ ╷ │ + ╷ ╷ ╷ ╷ │ + ╷ ╷ ▼ ╷ │ + ╷ └▶┌────────────────────◀┘ │ + ╷ │ │ │ + └╶╶╶▶│ Codex │◀───┘ + │ │ + └────────────────────┘ + ╷ + ╷ + ╷ + ╷ + ────── ╷ ────── + ─│── ───│ ╷ ─│── ───│ + │ │ R1 ╷ R2 │ │ +│ │ ╷ │ │ +│ Validator │ ◀╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶▶ │ Validator │ +│ │ │ │ + │ │ │ │ + ─│── ───│ ─│── ───│ + ────── ────── + + Validators are too busy +``` + +Edit/view: https://cascii.app/b6a31 + +#### Impacts + +- **System Disruption**: Hosts might temporarily avoid penalties for not serving content, + reducing file availability and causing users to lose trust in the Codex protocol. + +#### Mitigation + +Codex requires a small fee for each request, which helps mitigate this threat. +Other mitigations are also possible: optimizing the validation process to make proof +checks faster, limiting the number of storage requests per IP, and setting a minimum +file upload size. + +### Lazy Client + +#### Scenario + +A client may try to disrupt the network by making storage requests but never providing the +actual data to storage providers who are trying to fill the storage slots. + +#### Impacts + +- **Wasting Resources**: Storage providers waste their resources trying to store data that + never gets provided, making the network less efficient. + +#### Mitigation + +The transaction cost for each request helps prevent this attack. The more requests the attacker +makes, the higher the cost will be because of rising gas fees and block fill rates. +This makes it expensive for attackers to keep sending fake requests and spamming the network. + +### Censoring + +#### Scenario + +A Storage provider tries to block access to specific CIDsfrom the network in order to censor +certain content. This could also happen during a repair process when a service provider tries +to stop a freed slot from being repaired by not sharing the necessary data. + +#### Impacts + +- **Censored Content**: The service prodivder may stop users from accessing certain data, + preventing them from retrieving content they need. +- **Data Unavailability**: If the service provider tries to block data during a repair, + it could stop the network from restoring missing files, making the data unavailable. +- **Trust Issues**: Users may lose trust in the network if they believe that some service providers + can block or censor content. + +#### Mitigation + +Even if one SP withholds certain content, the dataset and the blocked CID can be rebuilt using +chunks from other service providers. This means that the censored CID can still be accessed +through other nodes, making the attack less successful. + +### Greedy + +#### Scenario + +A storage provider tries to fill multiple slots in a single request. This can be harmful because +it allows a single SP to control more resources than intended. + +#### Impacts + +- **Resource Control**: Reducing fairness and spreading resources not reparted. +- **Network Inefficiency**: Limit the opportunity for other SPs to participate, affecting the + overall efficiency of the network. + +#### Mitigation + +The expanding window mechanism helps prevent this attack. It makes sure that no single SP can fill +all the slots in a request by gradually opening up space for other service providers. +This works most of the time, but it may not be fully effective once the request is about to expire. + +### Sticky + +#### Scenario + +A storage provider tries to keep control of a storage slot during a contract renewal. The SP does +this by withholding the data from other SPs and waiting until the expanding window allows them to +fill the slot again. Since they already have the data, they can act faster than others and fill +the slot before anyone else. + +#### Impacts + +- **Unfair Advantage**: The service provider gains an unfair advantage by being able to renew the + contract without giving other SPs a fair chance. +- **Network Centralization**: Llead to fewer service providers handling more data, making the network + less balanced. + +#### Mitigation + +The attack is difficult and unlikely to work unless the service provider controls a large part of the +network. The expanding window mechanism also helps by spreading out control and giving other SPs a +fair chance to fill the slots. + ## Elevation of privilege Threat action intending to gain privileged access to resources in order to gain unauthorized access @@ -736,7 +895,7 @@ to information or to compromise a system. #### Scenario An attacker finds a vulnerability in Codex’s smart contract after it’s deployed. Anyone can call it. -The attacker uses this to change deal terms in their favor, taking control of the protocol. +The attacker uses this to change deal terms in their favor, taking over the funds. ``` ┌────────────────────────────┐ From 1f349ce7130d73fd70471b01d7d2d58d82bbfee1 Mon Sep 17 00:00:00 2001 From: Arnaud Date: Tue, 22 Apr 2025 13:40:36 +0200 Subject: [PATCH 11/14] Add multiple updates and DREAD score calculation --- evaluations/threat-modeling.md | 902 ++++++++++++++++++++++----------- 1 file changed, 592 insertions(+), 310 deletions(-) diff --git a/evaluations/threat-modeling.md b/evaluations/threat-modeling.md index 40474ec..851d2c0 100644 --- a/evaluations/threat-modeling.md +++ b/evaluations/threat-modeling.md @@ -10,52 +10,60 @@ serve as a starting point for directives in a security audit. The scope includes ## Methodology -The [STRIDE][1] framework is used due to its simplicity and the ability to quickly build -an analysis. -The [PASTA][2] framework was considered but is more business-oriented and suited for mature -projects. Additionally, its process is heavier than STRIDE's. +The STRIDE framework is +used due to its simplicity and ability to quickly build an analysis. +The PASTA framework +was considered, but it is more business-oriented and suited for mature projects. +Additionally, its process is heavier than STRIDE's. -Threat modeling is an iterative process, requiring constant updates as features are added or -modified in the codebase. Documenting potential security vulnerabilities helps developers to -keep them in mind during the code implementation. +Threat modeling is an iterative process that requires constant updates as features are added or +modified in the codebase. Documenting potential security vulnerabilities helps developers +keep them in mind during code implementation. + +DREAD is used as a risk assessment model to evaluate and prioritize security threats. Scores range is from 0 (low) to 10 (high). Anyone is invited to contribute to this document, as it is a -[collective effort](https://www.threatmodelingmanifesto.org) rather than a one-person task. +collective effort rather than a one-person task. + +### References + +[Manifesto](https://www.threatmodelingmanifesto.org) +[STRIDE](https://owasp.org/www-community/Threat_Modeling_Process#stride) +[PASTA](https://cdn2.hubspot.net/hubfs/4598121/Content%20PDFs/VerSprite-PASTA-Threat-Modeling-Process-for-Attack-Simulation-Threat-Analysis.pdf) +[DREAD](https://threat-modeling.com/dread-threat-modeling) ## Analysis -| Category | Threat | Description | Impact | Mitigation | -| ---------------------- | ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | ---------------------------------------------------------- | -| Spoofing | [Phishing-Induced spoofing](#phishing-induced-spoofing) | Exploits the private key loaded directly into the app via phishing to send unwanted requests. | Draining the user's wallet funds, store unwanted content. | Use cold wallet. | -| Spoofing | [Same-Chain attack replays](#same-chain-attack-replays) | Reuses a signed transaction on the same chain to spoof user actions. | Drained wallet funds. | Include a unique nonce in request data. | -| Spoofing | [Cross-Chain attack replays](#cross-chain-attack-replays) | Replays a signed transaction on another chain. | Drained wallet funds. | Implement EIP-712. | -| Spoofing | [Client spoofing via API](#client-spoofing-via-api) | Access to the exposed node to use the API. | Node full API access. | Educate users. | -| Tampering | [Fake proofs](#fake-proofs) | The storage provider sends fake proofs. | Contracts reward without actual data storage, reducing network reliability. | Require random challenges periodically. | -| Tampering | [markProofAsMissing re-entrency](#markproofasmissing-re-entrency) | The validator uses re-entrancy to slash multiple times. | Excessive collateral slashing of the host, proof validation failure. | Apply the `Checks-Effects-Interactions` pattern. | -| Repudiation | [Denial of file upload](#denial-of-file-upload) | User denies uploading illegal content. | Reputation impact and trust failure | Make a clear legal statement. | -| Repudiation | [Clever host](#clever-host) | Storage provider abandon its duties for a better opportunity. | Reduces network reliability. | Slash collateral and reward repairing slot. | -| Information disclosure | [Uploaded files exposed](#uploaded-files-exposed) | Non encrypted files can be reconstructed. | Reputation and privacy exposure. | Add encryption layer. | -| Elevation of privilege | [Exploring a vulnerability](#exploring-a-vulnerability) | The attacker exploits a vulnerability to take over the smart contracts. | System Disruption. | Upgradable contracts and / or admin role. | -| Denial of service | [Lazy host](#lazy-host) | Host reserves a slot, but doesn't fill it | System Disruption. | Multiple reservations. | -| Denial of service | [Lazy host](#lazy-host) | Host reserves a slot, but doesn't fill it | System Disruption. | Multiple reservations. | -| Overload attack | [Overload attack](#overload-attack) | Massive small requests to overload validators. | System Disruption. | Client doesn't release content on the network. | -| Denial of service | [Lazy Client](#lazy-client) | Starting request fees. | System Disruption. | Transaction cost | -| Denial of service | [Censoring](#censoring) | Acts like a lazy host for specific CIDs that it tries to censor fees. | System Disruption. | Dataset and CID and be rebuilt by other storage providers. | -| Denial of service | [Greedy](#greedy) | Storage provider tries to fill multiple slots in a request | System Disruption. | Expanding window mechanism | -| Denial of service | [Sticky](#sticky) | Storage provider tries to fill the same slot in a contract renewal. | System Disruption. | Expanding window mechanism | +| Category | Threat | Impact | Danger | +| ---------------------- | ------------------------------------------------------- | --------------------------------- | ------ | +| Spoofing | [Phishing](#phishing) | Financial, integrity | ⚠️ | +| Spoofing | [Same-Chain replay](#same-chain-replay) | Financial | 🛡️ | +| Spoofing | [Cross-Chain replay](#cross-chain-replay) | Financial | ⚠️ | +| Spoofing | [API exposed](#api-exposed) | Abuse | ⚠️ | +| Tampering | [Fake proofs](#fake-proofs) | Financial, disruptability | 🛡️ | +| Tampering | [Reentrancy](#Reentrancy) | Financial, integrity | ⚠️ | +| Repudiation | [Clever host](#clever-host) | Disruptability | 🛡️ | +| Information disclosure | [Data exposed](#data-exposed) | Reputation, privacy | ⚠️ | +| Denial of service | [Lazy host](#lazy-host) | Disruptability | 🛡️ | +| Overload attack | [Overload attack](#overload-attack) | Disruptability | ⚠️ | +| Denial of service | [Lazy Client](#lazy-client) | Disruptability | 🛡️ | +| Denial of service | [Censoring](#censoring) | Censorship, disruptability, trust | 🛡️ | +| Denial of service | [Greedy](#greedy) | Unfairness, disruptability | 🛡️ | +| Denial of service | [Sticky](#sticky) | Unfairness, centralization | 🛡️ | +| Elevation of privilege | [Exploring a vulnerability](#exploring-a-vulnerability) | Financial, disruptability | 🔥 | ## Spoofing Threat action aimed at impersonating users or storage providers to access or manipulate files and contracts in the network. -### Phishing-Induced spoofing +### Phishing #### Scenario When starting a Codex node, the user must load his private key to pay for initiating new -storage requests. This private key is loaded into memory, and there is no authentication -process to use the API. An attacker could reach the user via email phishing, +storage requests. This private key is stored in memory, and there is no authentication +process required to use the API. An attacker could reach the user via email phishing, pretending to be from Codex. The email might redirect to a malicious website or include a form that, upon the user's click, triggers a request to the Codex node to create a new storage request. @@ -117,17 +125,17 @@ Edit/view: https://cascii.app/437bc This could lead to two issues: -- **Financial Loss**: Malicious requests drain user wallet funds -- **Unwanted Content**: Attackers force storage of insecure or illegal files via - malicious CIDs, risking legal or reputational harm. +- **Financial**: Malicious requests drain user wallet funds. +- **Integrity**: Attackers force the storage of insecure or illegal files via malicious CIDs, + risking legal or reputational harm. #### Mitigation Typically, such web phishing attacks are mitigated by authentication or a -[custom header](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#employing-custom-request-headers-for-ajaxapi) to verify the request’s legitimacy. +custom header to verify the request’s legitimacy. However, Codex does not have an authentication mechanism, making options like CSRF -tokens impractical and using a custom header would provide a poor user experience +tokens impractical. Using a custom header would also provide a poor user experience in Codex, as users would need to set the header manually, which is cumbersome and error-prone. Users can reduce the risk of significant fund drainage by employing a hot wallet with @@ -140,12 +148,29 @@ While this strategy mitigates the financial impact of unwanted storage requests, not address the storage of unwanted or illegal content. An attacker could still trick the user into storing harmful files via phishing. -### Same-Chain attack replays +#### DREAD score + +| Component | Score | Description | +| -------------------- | :---: | ---------------------------------------------------------------- | +| **Damage Potential** | 9 | Leads to fund loss and illegal content storage. | +| **Reproducibility** | 8 | Easy to repeat once phishing is set up. | +| **Exploitability** | 9 | Only requires a phishing form. | +| **Affected Users** | 7 | Targets many users running a node and unaware of security risks. | +| **Discoverability** | 3 | Finding individual Codex users to contact is non-trivial. | + +**Average DREAD Score:** **7.2** + +#### References + +[CSRF](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#employing-custom-request-headers-for-ajaxapi) +[Web 3 phishing attacks](https://drops.scamsniffer.io/scam-sniffer-2024-web3-phishing-attacks-wallet-drainers-drain-494-million/) + +### Same-Chain replay #### Scenario -An attacker reuses a user’s signed transaction on the same chain to spoof additional -requests, attempting to drain funds. +An attacker captures a previously signed transaction and resends it on the same blockchain. +Because the signature is still valid, the transaction is accepted, and the attacker can drain the user's funds. ``` ────── @@ -200,21 +225,36 @@ Edit/view: https://cascii.app/b28b7 #### Impacts -- **Financial Loss**: Duplicate requests drain user funds +- **Financial**: Duplicate requests can drain user funds. #### Mitigation -Include a unique, random `nonce` in the request data. This ensures signatures are unique -per request, preventing reuse on the same chain. Codex’s current implementation includes -this, fully mitigating the threat. +Include a unique, random `nonce` in the request data. This makes each signature unique and +prevents it from being reused on the same chain. -### Cross-Chain attack replays +#### DREAD Score + +| DREAD Component | Score | Description | +| -------------------- | :---: | ---------------------------------------------------- | +| **Damage Potential** | 8 | Can drain user funds through repeated transactions. | +| **Reproducibility** | 9 | Easy to repeat once a valid transaction is captured. | +| **Exploitability** | 8 | Requires access to a signed transaction. | +| **Affected Users** | 9 | Affects any user sending signed requests. | +| **Discoverability** | 7 | Easy to try for the attacker. | + +**Average DREAD Score:** **8.2** + +#### References + +[Quicknode](https://www.quicknode.com/guides/ethereum-development/smart-contracts/what-are-replay-attacks-on-ethereum#nonce) + +### Cross-Chain replay #### Scenario -An attacker captures a user’s signed transaction from one chain and replays it on another -with an identical `Marketplace.sol` contract. The signature, publicly visible in blockchain, -validates without needing the user’s private key, spoofing their intent. +An attacker captures a user’s signed transaction from a blockchain and replays it on +another chain that runs the same `Marketplace.sol` contract. Because the signature is +public and still valid, it can be used to replay the request and drain the user's funds. ``` ────── @@ -262,33 +302,52 @@ validates without needing the user’s private key, spoofing their intent. ╷ ╷ ╷ ╷ ╷ ╷ - ▼ ────── -┌──────────────────────┐ ─│ ─│ -│ │ │ │ -│ Chain 1001 │◀╶╶╶╶╶╶╶╶╶╶╶╶╶╶│ Attacker │ -│ │ │ │ -└──────────────────────┘ ─│ ─│ - ────── + ▼ ────── +┌──────────────────────┐ ─│ ─│ +│ │ │ │ +│ Chain 1001 │◀╶╶╶╶╶╶╶╶╶╶╶╶╶╶ │ Attacker │ +│ │ │ │ +└──────────────────────┘ ─│ ─│ + ────── + + ``` -Edit/view: https://cascii.app/9951e +Edit/view: https://cascii.app/673f2 #### Impacts -- **Financial Loss**: Replayed requests on another chain drain user funds +- **Financial**: Replayed requests on another chain can drain user funds. #### Mitigation -Implement EIP-712 to include chain-specific data in signed transaction, ensuring -signatures are valid only on the intended chain and preventing unauthorized replays -on other chains. +Implement EIP-712 to include chain-specific data in the signed transaction. +This ensures the signature is only valid on the intended chain and prevents unauthorized +replays on other chains. -### Client spoofing via API +#### DREAD Score: Cross-Chain Attack Replays + +| DREAD Component | Score | Description | +| -------------------- | :---: | -------------------------------------------------- | +| **Damage Potential** | 8 | Can drain user funds across multiple chains. | +| **Reproducibility** | 5 | Needs two contract deployments on two blockchains. | +| **Exploitability** | 7 | Needs access to a signed transaction. | +| **Affected Users** | 9 | Affects any user. | +| **Discoverability** | 7 | Easy to try for the attacker. | + +**Average DREAD Score:** **7.2** + +#### References + +[Quicknode](https://www.quicknode.com/guides/ethereum-development/smart-contracts/what-are-replay-attacks-on-ethereum#chain-id) + +### API exposed #### Scenario -A user starts a node locally and uses `api-bindaddr` with the value `0.0.0.0`. -Worse, he confuses port forwarding and enable it for the REST API as well. +A user starts a node locally and sets `api-bindaddr` to `0.0.0.0`. +Worse, the user mistakenly enables port forwarding for the REST API as well. +As a result, the API is exposed, and an attacker can send any requests he wants. ``` ────── @@ -331,14 +390,25 @@ Edit/view: https://cascii.app/b762d #### Impacts -- **Node full API control**: Attackers can send unauthorized API requests, draining funds - or storing illegal content. +- **Abuse**: Attackers can send API requests, draining funds or storing illegal content. #### Mitigation -Educate the user to not use `0.0.0.0` for `api-bindaddr` unless he really knows what he -is doing and not enabling the port forwarding for the REST API. A warning during the -startup could be displayed if `api-bindaddr` is not bound to localhost. +Educate users not to use `0.0.0.0` for `api-bindaddr` unless they fully understand the risks, +and to avoid enabling port forwarding for the API. A warning could be shown at startup +if `api-bindaddr` is not bound to `localhost`. + +#### DREAD Score + +| DREAD Component | Score | Description | +| -------------------- | :---: | ---------------------------------------------- | +| **Damage Potential** | 10 | Full API access. | +| **Reproducibility** | 5 | Easy if node is misconfigured and exposed. | +| **Exploitability** | 10 | Needs no exploit. | +| **Affected Users** | 2 | Affects users exposing their API by mistake. | +| **Discoverability** | 6 | Attackers can scan networks for exposed ports. | + +**Average DREAD Score:** **6.6** ## Tampering @@ -349,9 +419,9 @@ the network. #### Scenario -In the case of the proof verification is weak and proofs can be submitted and verified easily, -a storage provider could stop storing the data and attempts to send fake proofs, claiming they -are still hosting the content, using initial data received. +If proof verification is weak and proofs can be submitted and verified too easily, +a storage provider could stop storing the data and attempt to send fake proofs, +claiming they are still hosting the content using the initial data they received. ``` ────── @@ -370,14 +440,14 @@ are still hosting the content, using initial data received. │ │ │ Codex network │◀╶╶╶╶╶╶╶╶╶╶╶╶╶┐ │ │ ╷ -└────────────────────────┘ ╷ - ╷ ╷ - ╷ ╷ - ╷ Delete the file ╷ - ╷ Submit fake proof ╷ +└────────────────────────┘ + ╷ Delete the file + ╷ Submit fake proof ╷ ╷ ╷ ╷ ╷ ╷ + ╷ ╷ + ╷ ▼ ╷ ────── ╷ ─│ ─│ ╷ │ │ @@ -398,156 +468,111 @@ are still hosting the content, using initial data received. └────────────────────┘ ``` -Edit/view: https://cascii.app/9de0e +Edit/view: https://cascii.app/cc7e0 #### Impacts -- **Financial**: Attackers attempt to earn contract rewards at the end of the contract - without storing the file. -- **Availability**: The slot becomes unavailable from that storage provider, reducing - network reliability. +- **Financial**: Attackers try to earn contract rewards at the end of the contract without + actually storing the file. +- **Disruptability**: The slot becomes unavailable from that storage provider, + reducing network reliability. #### Mitigation -Codex issues periodic random challenges based on blockchain randomness to verify that -storage providers hold the data. Each failed challenge slashes the provider’s collateral. -After multiple failed proofs, the provider is removed from the contract, freeing the -slot for another provider. +Codex issues periodic random challenges, based on blockchain randomness, to verify that storage +providers still hold the data. Each failed challenge slashes the provider’s collateral. After multiple +failed proofs, the provider is removed from the contract, freeing the slot for another provider. -### markProofAsMissing re-entrency +#### DREAD Score + +| DREAD Component | Score | Description | +| -------------------- | :---: | -------------------------------------------------- | +| **Damage Potential** | 8 | Earns rewards without storing data. | +| **Reproducibility** | 6 | Easy if challenge system is weak or predictable. | +| **Exploitability** | 3 | Needs technical knowledge and protocol weaknesses. | +| **Affected Users** | 5 | Impacts users who stored data on "attacker" hosts. | +| **Discoverability** | 3 | Needs deep source code analysis to detect. | + +**Average DREAD Score:** **5.0** + +#### References + +[One File for the Price of Three: Catching Cheating Servers in Decentralized Storage Networks](https://web.archive.org/web/20240518000652/https://hackingdistributed.com/2018/08/06/PIEs/) + +### Reentrancy #### Scenario -A validator could exploit a reentrancy vulnerability in `markProofAsMissing` by re-entering -the function during an external token transfer, allowing multiple slashes and rewards -for a single missed proof within one transaction. +The `markProofAsMissing` function, along with related functions such as `fillSlot` and `requestStorage`, +makes external calls (e.g., `transferFrom`) before completing internal state updates. +This opens the door to reentrancy attacks, where an attacker can re-enter the function and trigger +multiple operations in a single transaction, such as slashing collateral multiple times +or claiming validator rewards repeatedly. ```js // Generated from slither report -Reentrancy in Marketplace.markProofAsMissing(SlotId,Periods.Period) (contracts/Marketplace.sol#338-360): +Reentrancy in Marketplace.fillSlot(RequestId,uint64,Groth16Proof) (contracts/Marketplace.sol#187-251): External calls: - - assert(bool)(_token.transfer(msg.sender,validatorRewardAmount)) (contracts/Marketplace.sol#352) + - _transferFrom(msg.sender,collateralAmount) (contracts/Marketplace.sol#234) + - ! _token.transferFrom(sender,receiver,amount) (contracts/Marketplace.sol#688) Event emitted after the call(s): - - RequestFailed(requestId) (contracts/Marketplace.sol#396) - - _forciblyFreeSlot(slotId) (contracts/Marketplace.sol#358) - - SlotFreed(requestId,slot.slotIndex) (contracts/Marketplace.sol#385) - - _forciblyFreeSlot(slotId) (contracts/Marketplace.sol#358) + - RequestFulfilled(requestId) (contracts/Marketplace.sol#249) + - SlotFilled(requestId,slotIndex) (contracts/Marketplace.sol#241) +Reentrancy in Marketplace.markProofAsMissing(SlotId,Periods.Period) (contracts/Marketplace.sol#345-371): + External calls: + - ! _token.transfer(msg.sender,validatorRewardAmount) (contracts/Marketplace.sol#361) + Event emitted after the call(s): + - RequestFailed(requestId) (contracts/Marketplace.sol#407) + - _forciblyFreeSlot(slotId) (contracts/Marketplace.sol#369) + - SlotFreed(requestId,slot.slotIndex) (contracts/Marketplace.sol#396) + - _forciblyFreeSlot(slotId) (contracts/Marketplace.sol#369) +Reentrancy in Marketplace.requestStorage(Request) (contracts/Marketplace.sol#132-177): + External calls: + - _transferFrom(msg.sender,amount) (contracts/Marketplace.sol#174) + - ! _token.transferFrom(sender,receiver,amount) (contracts/Marketplace.sol#688) + Event emitted after the call(s): + - StorageRequested(id,request.ask,_requestContexts[id].expiresAt) (contracts/Marketplace.sol#176) ``` -``` - ────── - ─│ ─│ - │ │ - │ User │ - │ │ - ─│ ─│ - ────── - ╷ - Storage ╷ - Request ╷ - ▼ - ┌───────────────────────────┐ -Re-entrency │ │ - │ │ - ┌╶╶╶╶╶╶╶╶╶╶▶│ Codex network │ - ╷ │ │ - ╷ │ │ - ╷ ▲───────────────────────────┘ - ╷ ╷ ╷ - ╷ ╷ ╷ - ────── ╷ ╷ ────── - ─│ ─│ ╷ ╷ ─│ ─│ - │ │ ╷ ╷ │ │ - │ Validator │╶╶╶╶╶┘ ╷ │ SP │ - │ │ ╷ │ │ - ─│ ─│ ╷ ─│ ─│ - ────── ╷ ────── - ▲ ╷ ▲ - ╷ ▼ ╷ - ╷ ┌────────────────────┐ ╷ - └╶╶╶╶╶╶╶╶╶╶╶╶╶╶│Slot 1│Slot 2│Slot 3│╶╶╶╶╶╶╶╶╶╶╶╶╶╶┘ - └────────────────────┘ -``` - -Edit/view: https://cascii.app/0e182 - -#### Impacts - -- **Financial**: Attackers could earn multiple validation rewards and excessively - slash the host’s collateral for a single missed proof, draining funds unfairly. -- **Validation**: Repeated slashing disrupts PoR verification, potentially marking - valid proofs as missing and undermining trust. - #### Mitigation -Apply the `Checks-Effects-Interactions` pattern by updating state before the external -`_token.transfer` call. -Use OpenZeppelin’s `ReentrancyGuard` to block reentrant calls. +Apply the `Checks-Effects-Interactions` pattern. +Use OpenZeppelin’s `ReentrancyGuard` to prevent nested entry into sensitive functions. -[1]: https://owasp.org/www-community/Threat_Modeling_Process#stride -[2]: https://cdn2.hubspot.net/hubfs/4598121/Content%20PDFs/VerSprite-PASTA-Threat-Modeling-Process-for-Attack-Simulation-Threat-Analysis.pdf +#### DREAD Score + +| DREAD Component | Score | Description | +| -------------------- | :---: | ----------------------------------------------------- | +| **Damage Potential** | 8 | Can drain funds via multiple slashes and rewards. | +| **Reproducibility** | 2 | Works consistently if reentrancy is not prevented. | +| **Exploitability** | 2 | Requires contract-level knowledge and timing control. | +| **Affected Users** | 6 | Affects all contracts using `markProofAsMissing`. | +| **Discoverability** | 6 | Can be found through careful contract audit. | + +**Average DREAD Score:** **4.8** + +#### References + +[Solidity](https://docs.soliditylang.org/en/latest/security-considerations.html#reentrancy) +[Checks-Effects-Interactions](https://docs.soliditylang.org/en/latest/security-considerations.html#use-the-checks-effects-interactions-pattern) +[Reentrancy guard](https://docs.openzeppelin.com/contracts/4.x/api/security#ReentrancyGuard) ## Repudiation Threat action aimed at denying responsibility for uploading files or agreeing to storage contracts in the network. -### Denial of file upload - -#### Scenario - -A user uploads illegal content to Codex and later denies initiating the request, -attempting to escape responsibility. - -``` - ────── - ─│ ─│ - │ │ - │ Anonymous │ - │ │ - ─│ ─│ - ────── - ╷ - Illegal ╷ - Content ╷ - ▼ - ┌───────────────────┐ - │ │ - │ Codex protocol │ - │ │ - └───────────────────┘ - ▲ - ╷ - ╷ - ╷ - ────── ╷ ────── - ─│ ─│ ╷ ─│ ─│ -│ │ ╷ │ │ -│ User │╶╶╶╶╶╶╶╶└╶╶╶╶╶╶╶╶│ User │ -│ │ │ │ - ─│ ─│ Download ─│ ─│ - ────── ────── -``` - -Edit/view: https://cascii.app/5b9a9 - -#### Impacts - -- **Reputation**: Codex could be used to distribute illegal content, leading to a - loss of trust in the protocol. - -#### Mitigation - -Make a clear statement that Codex is not responsible for such content and warn users of the -potential risk for downloading an unknown CID. - ### Clever host #### Scenario -In this attack, an SP could fill a slot, and while fulfilling its duties, see -that a better opportunity has arisen, and abandon its duties in the first slot -to fill the second slot. +A storage provider can fill a slot and begin fulfilling its duties. +However, if a more profitable opportunity appears, the provider may abandon the first slot +in favor of the new one. + +This behavior is not intended to harm the network but to pursue a better opportunity. +It is considered a form of repudiation, as the provider is effectively denying +its original commitment in order to prioritize another. ``` ────── @@ -583,107 +608,143 @@ Fill Request 1 Slot 2 ╷ ╷ ─│── ───│ to fill Request 2 Slot 2 ╷ │ │ ▼ │ │ ┌────────────────────┐ - │ Clever host │────────────────│Slot 1│Slot 2│Slot 3│ + │ Clever host │╶╶╶╶╶╶╶╶╶╶╶╶╶╶▶ │Slot 1│Slot 2│Slot 3│ │ │ └────────────────────┘ │ │ ─│── ───│ ────── ``` -Edit/view: https://cascii.app/db2da +Edit/view: https://cascii.app/93704 #### Impacts -- **Availability**: The slot becomes unavailable from that storage provider, +- **Disruptability**: The slot becomes unavailable from that storage provider, reducing network reliability. #### Mitigation This attack is mitigated by the storage provider losing its request collateral for the first -slot once it is abandoned. Additionally, once the storage provider fills the first slot, it -will accrue rewards over time that will not be paid out until the request -successfully completes. These rewards act as another disincentive for the storage -provider to abandon the slot. +slot once it is abandoned. Additionally, after filling the first slot, the provider begins +to accrue rewards over time, but these rewards are only paid out if the request is +successfully completed. This delayed payout acts as an additional disincentive for the +storage provider to abandon the slot. +`` + +#### DREAD Score + +| DREAD Component | Score | Description | +| -------------------- | :---: | -------------------------------------------------- | +| **Damage Potential** | 5 | Reduces network reliability and causes slot waste. | +| **Reproducibility** | 5 | Easy to repeat if better-paying slots are common. | +| **Exploitability** | 4 | Requires strategy but no technical exploit. | +| **Affected Users** | 4 | Affects clients relying on abandoned slots. | +| **Discoverability** | 3 | Hard to detect unless monitored closely. | + +**Average DREAD Score:** **4.2** ## Information disclosure Information disclosure occurs when private or sensitive information such as user data, file contents, or system secrets is unintentionally or maliciously revealed to unauthorized parties. -### Uploaded files exposed +### Data exposed #### Scenario -A user uploads a confidential file to Codex. Storage providers store non encrypted slots -of the file. Without encryption, storage providers could agree to gather slots and +A user uploads a confidential file to Codex. Storage providers store unencrypted slots +of the file. Without encryption, providers could coordinate to gather these slots and reassemble the full content. +Additionally, sensitive metadata, such as file location or identifiers, may be exposed. +Other users could access this information, creating a privacy risk. ``` - ────── - ─│ ─│ - │ │ - │ User │ - │ │ - ─│ ─│ ────── - ────── ─│ ─│ - ╷ │Better │ - ╷ │Opportunity│ - ╷ │ │ - ╷ ─│ ─│ - ▼ ────── - ┌────────────────────┐ ╷ - │ │ ╷ - │ Codex network │◀╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶┘ - │ │ - └────────────────────╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶┐ - ╷ ╷ - Request 1 ╷ ╷ - ╷ ╷ - ╷ ╷ - ▼ ╷ - ┌────────────────────┐ ╷ - │Slot 1│Slot 2│Slot 3│ ╷ - └────────────────────┘ ╷ - ╷ ╷ - ╷ ╷ -Fill Request 1 Slot 2 ╷ ╷ - ▼ ╷ - ────── Abandon Request 1 Slot 2 ╷ - ─│── ───│ to fill Request 2 Slot 2 ╷ - │ │ ▼ - │ │ ┌────────────────────┐ - │ Clever host │◀╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶│Slot 1│Slot 2│Slot 3│ - │ │ └────────────────────┘ - │ │ - ─│── ───│ - ────── + ────── + ─│ ─│ + │ │ + │ User │ + │ │ + ─│ ─│ + ────── + ╷ + Upload a file ╷ + ╷ + ▼ Access to the ────── + ┌─────────────────┐ file metadata ─│ ─│ + │ │ │ │ + │ Codex │◀╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶│ User │ + │ │ │ │ + └─────────────────┘ ─│ ─│ + │ ────── + │ + │ + ▼ + ┌────────────────────┐ + ┌╶╶╶╶╶╶╶╶│Slot 1│Slot 2│Slot 1│╶╶╶╶╶╶╶╶╶┐ + ╷ └────────────────────┘ ╷ + ╷ ╷ ╷ + ╷ ╷ ╷ + ▼ ▼ ▼ + ────── ────── ────── + ─│ ─│ ─│ ─│ ─│ ─│ +│ │ │ │ │ │ +│ SP │ │ SP │ │ SP │ +│ │ │ │ │ │ + ─│ ─│ ─│ ─│ ─│ ─│ + ────── ────── ────── + ╷ ╷ ╷ + ╷ ╷ ╷ + ╷ ▼ ╷ + ╷ ┌──────────────────────┐ ╷ + ╷ │ │ ╷ + └╶╶╶╶╶╶▶ │ Original file │◀╶╶╶╶╶╶┘ + │ │ + └──────────────────────┘ ``` -Edit/view: https://cascii.app/ef5ab +Edit/view: https://cascii.app/07f58 #### Impacts - **Reputation**: Codex cannot guarantee confidentiality, leading to a loss of trust in the protocol. -- **Privacy**: Exposure of sensitive user data could violate privacy, potentially - resulting in legal or regulatory consequences. +- **Privacy**: Exposure of sensitive user data could violate privacy and potentially + result in legal or regulatory consequences. #### Mitigation -Implement encryption to ensure that only authorized users can decrypt and access the file contents. +Encrypt files on the client side before upload to ensure that only authorized users +can decrypt and access the contents. In addition, sensitive metadata should be removed or +encrypted where possible to reduce the risk of privacy leaks. + +#### DREAD Score + +| DREAD Component | Score | Description | +| -------------------- | :---: | --------------------------------------------------------------- | +| **Damage Potential** | 7 | Sensitive data or metadata may be publicly exposed. | +| **Reproducibility** | 4 | Easy if metadata are exposed, harder for full file content. | +| **Exploitability** | 2 | Requires file access and slot coordination. | +| **Affected Users** | 7 | Affects users storing unencrypted or sensitive content. | +| **Discoverability** | 8 | Exposed content and metadata can be browsed in the source code. | + +**Average DREAD Score:** **5.6** + +[References] + +[Metadata = Surveillance](https://www.schneier.com/blog/archives/2014/03/metadata_survei.html?utm_source=chatgpt.com) ## Denial of service +Threat action intended to make a service or resource unavailable to its intended users by overloading, +blocking, or disrupting normal operations. + ### Lazy host #### Scenario -In the case of a single reservation system, matching storage providers are assigned to -slot reservation by a 1-1 relation, meaning that there is one storage provider -for one reservation. -A storage provider reserves a slot, but waits to fill the slot hoping a better -opportunity will arise, in which the reward earned in the new opportunity would be -greater than the reward earned in the original slot. +In a single-reservation system, each slot is assigned to one storage provider through a 1-to-1 match. +A storage provider may reserve a slot but delay filling it, hoping a better opportunity will appear — +one that offers a higher reward than the original slot. ``` ────── ────── @@ -728,23 +789,34 @@ Edit/view: https://cascii.app/6144e #### Impacts -- **Availability**: The storage request will fail because the storage provider assigned to the slot - decided not to fill it for a better opportunity, leaving the slot empty. +- **Disruptability**: The storage request fails because the assigned storage provider + chooses not to fill the slot, leaving it empty in favor of a better opportunity. #### Mitigation -This attack is mitigated by allowing for multiple reservations per slot. -All storage providers that have secured a reservation (capped at three) will race to fill the slot. -Thus, if one or more storage providers that have reserved the slot decide to -pursue other opportunities, the other storage providers that have reserved the slot will -still be able to fill the slot. +This attack is mitigated by allowing multiple reservations per slot. +Up to three storage providers can reserve the same slot and race to fill it. +If one or more providers choose to pursue other opportunities, the others can still +complete the request, ensuring reliability. + +#### DREAD Score + +| DREAD Component | Score | Description | +| -------------------- | :---: | -------------------------------------------------------------- | +| **Damage Potential** | 7 | Fails storage requests, but no direct economic loss. | +| **Reproducibility** | 5 | Easy to repeat if system allows only single reservations. | +| **Exploitability** | 3 | Requires strategic delay by the storage provider. | +| **Affected Users** | 4 | Affects users assigned to non-participating storage providers. | +| **Discoverability** | 4 | Hard to detect until the storage deadline is missed. | + +**Average DREAD Score:** **4.6** ### Overload attack #### Scenario -An attacker runs many small requests that generate high-volume transactions, overwhelming -validators and delaying their ability to detect missed proofs. +An attacker sends many small storage requests that generate a high volume of transactions. +This overloads validators and delays their ability to detect missed proofs in time. ``` ────── @@ -793,109 +865,307 @@ Edit/view: https://cascii.app/b6a31 #### Impacts -- **System Disruption**: Hosts might temporarily avoid penalties for not serving content, +- **Disruptability**: Hosts might temporarily avoid penalties for not serving content, reducing file availability and causing users to lose trust in the Codex protocol. #### Mitigation -Codex requires a small fee for each request, which helps mitigate this threat. -Other mitigations are also possible: optimizing the validation process to make proof -checks faster, limiting the number of storage requests per IP, and setting a minimum -file upload size. +Codex requires a small fee for each request, which helps limit spam. +Additional mitigations include optimizing the validation process to make proof checks faster, +limiting the number of storage requests per IP address, and setting a minimum file upload size. + +#### DREAD Score + +#### DREAD Score: Overload Attack + +| DREAD Component | Score | Description | +| -------------------- | :---: | -------------------------------------------------------------- | +| **Damage Potential** | 8 | Temporarily weakens validation and file availability. | +| **Reproducibility** | 2 | Hard to repeat. | +| **Exploitability** | 2 | Requires ability to send many valid requests at scale. | +| **Affected Users** | 10 | Affects all users. | +| **Discoverability** | 4 | Noticeable during high load but hard to trace to one attacker. | + +**Average DREAD Score:** **5.2** ### Lazy Client #### Scenario -A client may try to disrupt the network by making storage requests but never providing the -actual data to storage providers who are trying to fill the storage slots. +A client may try to disrupt the network by making storage requests but never provides +the actual data to the storage providers attempting to fill those slots. +As a result, the slots remain unfilled, wasting provider resources and delaying other requests. + +``` + ────── + ─│ ─│ + │ │ + │ User │ + │ │ + ─│ ─│ + ────── + ╷ + Upload a file ╷ + ╷ + ▼ + ┌─────────────────┐ + │ │ + │ Codex │ + │ │ + └─────────────────┘ + ╷ + Reservations ╷ + without releasing ╷ + data ▼ + ┌────────────────────┐ + ┌╶╶╶╶╶╶╶╶│Slot 1│Slot 2│Slot 1│╶╶╶╶╶╶╶╶╶┐ + ╷ └────────────────────┘ ╷ + ╷ ╷ ╷ + ╷ ╷ ╷ + ▼ ▼ ▼ + ────── ────── ────── + ─│ ─│ ─│ ─│ ─│ ─│ +│ │ │ │ │ │ +│ SP │ │ SP │ │ SP │ +│ │ │ │ │ │ + ─│ ─│ ─│ ─│ ─│ ─│ + ────── ────── ────── +``` + +Edit/view: https://cascii.app/c973a #### Impacts -- **Wasting Resources**: Storage providers waste their resources trying to store data that - never gets provided, making the network less efficient. +- **Disruptability**: Storage providers waste resources trying to store data that + is never delivered, reducing the overall efficiency of the network. #### Mitigation -The transaction cost for each request helps prevent this attack. The more requests the attacker -makes, the higher the cost will be because of rising gas fees and block fill rates. -This makes it expensive for attackers to keep sending fake requests and spamming the network. +The transaction cost for each storage request helps prevent this attack. +The more fake requests an attacker sends, the higher the total cost becomes due to +rising gas fees and block fill rates. +This makes it economically unfeasible to sustain large-scale spamming. + +#### DREAD Score + +| DREAD Component | Score | Description | +| -------------------- | :---: | --------------------------------------------------------------- | +| **Damage Potential** | 5 | Wastes storage provider resources and slows the system. | +| **Reproducibility** | 2 | Possible but limited by transaction costs and network capacity. | +| **Exploitability** | 2 | Requires funding. | +| **Affected Users** | 8 | Affects most users during periods of slot disruption. | +| **Discoverability** | 3 | Hard to discover. | + +**Average DREAD Score:** **4.0** ### Censoring #### Scenario -A Storage provider tries to block access to specific CIDsfrom the network in order to censor -certain content. This could also happen during a repair process when a service provider tries -to stop a freed slot from being repaired by not sharing the necessary data. +A storage provider attempts to block access to specific CIDs in order to censor certain content. +This can also occur during the repair process, where the provider refuses to share the required +data, preventing a freed slot from being restored by others in the network. + +``` + ────── + ─│ ─│ + │ │ + │ User │ + │ │ + ─│ ─│ + ────── + ╷ + Upload a file ╷ + ╷ + ▼ + ┌─────────────────┐ + │ │ + │ Codex │◀╶╶╶╶╶╶╶╶╶╶╶╶╶╶┐ + │ │ ╷ + ╷─────────────────╷ ╷ + ╷ ╷ ╷ + ╷ ╷ Block the ╷ +Store the file ╷ ╷ content ╷ ────── + ╷ ╷ ┌───────────┐ ─│ ─│ + ╷ ────── ╷ │ │ │ │ + ╷ ─│ ─│ ╷ │ CID │◀╶╶╶╶╶╶╶╶│ User │ + ╷ │ │ ╷ │ │ │ │ + └╶▶│ SP │◀╶┘ └───────────┘ ─│ ─│ + │ │ ────── + ─│ ─│ + ────── +``` + +Edit/view: https://cascii.app/e1d00 #### Impacts -- **Censored Content**: The service prodivder may stop users from accessing certain data, - preventing them from retrieving content they need. -- **Data Unavailability**: If the service provider tries to block data during a repair, +- **Censorship**: The storage provider may prevent users from accessing certain data, + stopping them from retrieving content they need. +- **Disruptability**: If the storage provider blocks data during a repair, it could stop the network from restoring missing files, making the data unavailable. -- **Trust Issues**: Users may lose trust in the network if they believe that some service providers +- **Trust**: Users may lose trust in the network if they believe some providers can block or censor content. #### Mitigation -Even if one SP withholds certain content, the dataset and the blocked CID can be rebuilt using -chunks from other service providers. This means that the censored CID can still be accessed -through other nodes, making the attack less successful. +Even if one storage provider withholds certain content, the dataset and the blocked CID +can be rebuilt using chunks from other providers. This means the censored CID can still +be accessed through other nodes, reducing the impact of the attack. ### Greedy #### Scenario -A storage provider tries to fill multiple slots in a single request. This can be harmful because -it allows a single SP to control more resources than intended. +A storage provider attempts to fill multiple slots in the same storage request by quickly submitting +multiple offers. This gives them a larger share of the deal, limiting participation by other providers. + +``` + ────── + ─│ ─│ + │ │ + │ User │ + │ │ + ─│ ─│ + ────── + ╷ +Upload a file ╷ + ╷ + ▼ + ┌─────────────────┐ + │ │ + │ Codex │ + │ │ + └─────────────────┘ + ╷ + ╷ + ╷ + ╷ + ▼ + ┌────────────────────┐ + │Slot 1│Slot 2│Slot 3│ + └────────────────────┘ + ╷ ╷ ╷ + ╷ ╷ ╷ + └╶╶╶╶╶╶╷╶╶╶╶╶╶┘ + ╷ + ▼ + ────── + ─│ ─│ + │ │ + │ SP │ + │ │ + ─│ ─│ + ────── +``` + +Edit/view: https://cascii.app/f3984 #### Impacts -- **Resource Control**: Reducing fairness and spreading resources not reparted. -- **Network Inefficiency**: Limit the opportunity for other SPs to participate, affecting the - overall efficiency of the network. +- **Unfairness**: Allows one provider to control more resources than intended, reducing fairness + in slot allocation. +- **Disruptability**: Limits opportunities for other providers and reduces network decentralization. #### Mitigation -The expanding window mechanism helps prevent this attack. It makes sure that no single SP can fill -all the slots in a request by gradually opening up space for other service providers. -This works most of the time, but it may not be fully effective once the request is about to expire. +The expanding window mechanism helps prevent this attack. It gradually opens slot availability to more +storage providers, making it harder for one to dominate all slots early. However, near the expiration of +the request, the mechanism may be less effective, as fewer providers may be available to fill new slots in time. + +#### DREAD Score + +| DREAD Component | Score | Description | +| -------------------- | :---: | ------------------------------------------------------------- | +| **Damage Potential** | 5 | Reduces fairness; may lead to centralization over time. | +| **Reproducibility** | 6 | Easy to repeat with fast or automated submissions. | +| **Exploitability** | 2 | Requires timing advantage or faster infrastructure. | +| **Affected Users** | 6 | Affects any users sharing storage requests with greedy hosts. | +| **Discoverability** | 4 | Can go unnoticed unless provider patterns are analyzed. | + +**Average DREAD Score:** **4.6** ### Sticky #### Scenario -A storage provider tries to keep control of a storage slot during a contract renewal. The SP does -this by withholding the data from other SPs and waiting until the expanding window allows them to -fill the slot again. Since they already have the data, they can act faster than others and fill -the slot before anyone else. +A storage provider tries to retain control of a storage slot during contract renewal. +They do this by withholding the data from other providers and waiting for the expanding +window to open. Since they already have the data, they can act faster than others +and fill the slot again before anyone else. + +``` + ────── + ─│ ─│ + │ │ + │ User │ + │ │ + ─│ ─│ + ────── + ╷ +Upload a file ╷ + ╷ + ▼ + ┌─────────────────┐ + │ │ + │ Codex │ + │ │ + └─────────────────┘ + ╷ + ╷ ┌───────────────────────┐ + ╷ │ │ + Store the file ╷ │ Contract renewal │ + ╷ │ │ + ╷ └───────────────────────┘ + ╷ ▲ + ▼ ╷ + ────── ╷ + ─│ ─│ ╷ + │ │ ╷ + │ SP │╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶┘ + │ │ Witholding data + ─│ ─│ and wait for expanding + ────── window to open +``` + +Edit/view: https://cascii.app/db8fa #### Impacts -- **Unfair Advantage**: The service provider gains an unfair advantage by being able to renew the - contract without giving other SPs a fair chance. -- **Network Centralization**: Llead to fewer service providers handling more data, making the network - less balanced. +- **Unfairness**: The storage provider gains an unfair advantage by renewing the + contract without giving others a fair opportunity. +- **Centralization**: Can lead to fewer storage providers handling more data, + making the network less balanced and more centralized. #### Mitigation -The attack is difficult and unlikely to work unless the service provider controls a large part of the -network. The expanding window mechanism also helps by spreading out control and giving other SPs a -fair chance to fill the slots. +This attack is difficult to succeed with unless the storage provider controls a large +portion of the network. The expanding window mechanism helps prevent this by spreading +out renewal opportunities and giving other providers a fair chance to fill the slots. + +#### DREAD Score + +| DREAD Component | Score | Description | +| -------------------- | :---: | -------------------------------------------------------- | +| **Damage Potential** | 5 | Unfair slot control but no direct loss. | +| **Reproducibility** | 2 | Requires repeated timing success in renewal windows. | +| **Exploitability** | 2 | Hard with window mechanism. | +| **Affected Users** | 6 | Users who renew the storage contract. | +| **Discoverability** | 2 | Hard to detect unless slot filling is closely monitored. | + +**Average DREAD Score:** **3.4** ## Elevation of privilege -Threat action intending to gain privileged access to resources in order to gain unauthorized access -to information or to compromise a system. +Threat action intending to gain privileged access to resources in order to gain unauthorized access to information or to compromise a system. ### Exploring a vulnerability #### Scenario -An attacker finds a vulnerability in Codex’s smart contract after it’s deployed. Anyone can call it. -The attacker uses this to change deal terms in their favor, taking over the funds. +An attacker discovers a vulnerability in Codex’s smart contract after it is deployed. +Since anyone can interact with the contract, the attacker exploits the vulnerability to change +deal terms in their favor and take control of the funds. ``` ┌────────────────────────────┐ @@ -945,10 +1215,22 @@ Edit/view: https://cascii.app/23869 #### Impacts -- **Financial Loss**: Attackers could tweak deals to steal funds or stop payments. -- **System Disruption**: The integrity of the Codex protocol is compromised, leading to a loss of trust. +- **Financial**: Attackers could modify deals to steal funds or block payments. +- **Disruptability**: The integrity of the Codex protocol is compromised, leading to a loss of trust. #### Mitigation -Use upgradable contracts to allow for future fixes. Additionally, implement temporary admin roles -requiring multiple approvals for changing critical settings. +Use upgradable contracts to enable future fixes. Additionally, implement temporary admin roles +with multi-signature approval for changing critical settings or logic. + +#### DREAD Score + +| DREAD Component | Score | Description | +| -------------------- | :---: | -------------------------------------------------------------- | +| **Damage Potential** | 10 | Full control over deal logic or funds. | +| **Reproducibility** | 9 | Easy to repeat once the vulnerability is known. | +| **Exploitability** | 5 | Requires finding and triggering a public contract weakness. | +| **Affected Users** | 10 | Affects all users using the vulnerable contract. | +| **Discoverability** | 5 | Harder to find, but public contract code helps skilled actors. | + +**Average DREAD Score:** **7.8** From cee5c070e77653bf8e007b9ca308da964f7d2c80 Mon Sep 17 00:00:00 2001 From: Arnaud Date: Tue, 22 Apr 2025 21:06:44 +0200 Subject: [PATCH 12/14] Apply minor changes --- evaluations/threat-modeling.md | 236 ++++++++++++++++----------------- 1 file changed, 113 insertions(+), 123 deletions(-) diff --git a/evaluations/threat-modeling.md b/evaluations/threat-modeling.md index 851d2c0..d3b3049 100644 --- a/evaluations/threat-modeling.md +++ b/evaluations/threat-modeling.md @@ -71,12 +71,12 @@ form that, upon the user's click, triggers a request to the Codex node to create ────── ─│ ─│ ┌────────────────┐ │ │ │ │ -│ Attacker │───────────▶│ Email phishing │ +│ Attacker │╶╶╶╶╶╶╶╶╶▶ │ Email phishing │ │ │ │ │ ─│ ─│ └────────────────┘ - ────── │ - • │ - • │ + ────── ╷ + • ╷ + • ╷ • ▼ • ────── • ─│ ─│ @@ -85,32 +85,32 @@ form that, upon the user's click, triggers a request to the Codex node to create • │ │ • ─│ ─│ • ────── - • │ - • │ - • │ Clicks on the phishing email - • │ - • │ + • ╷ + • ╷ + • ╷ Clicks on the phishing email + • ╷ + • ╷ • ▼ • ┌────────────────┐ • │ │ • │ Unsecure form │ • │ │ • └────────────────┘ - • │ - • │ Submits the form - • │ - • │ action=/storage/request/CIDMalicious method=POST - • │ input name="pricePerBytePerSecond" value="100000" + • ╷ + • ╷ Submits the form + • ╷ + • ╷ action=/storage/request/CIDMalicious method=POST + • ╷ input name="pricePerBytePerSecond" value="100000" • ▼ • ┌────────────────┐ • │ │ • │ Codex node │ • │ │ • └────────────────┘ - • │ - • │ POST /storage/request/CIDMalicious - • │ pricePerBytePerSecond: 1000000 - • │ + • ╷ + • ╷ POST /storage/request/CIDMalicious + • ╷ pricePerBytePerSecond: 1000000 + • ╷ • ▼ • ┌────────────────┐ • │ │ @@ -119,7 +119,7 @@ form that, upon the user's click, triggers a request to the Codex node to create └────────────────┘ ``` -Edit/view: https://cascii.app/437bc +Edit/view: https://cascii.app/21c64 #### Impacts @@ -325,17 +325,17 @@ Implement EIP-712 to include chain-specific data in the signed transaction. This ensures the signature is only valid on the intended chain and prevents unauthorized replays on other chains. -#### DREAD Score: Cross-Chain Attack Replays +#### DREAD Score | DREAD Component | Score | Description | | -------------------- | :---: | -------------------------------------------------- | | **Damage Potential** | 8 | Can drain user funds across multiple chains. | | **Reproducibility** | 5 | Needs two contract deployments on two blockchains. | | **Exploitability** | 7 | Needs access to a signed transaction. | -| **Affected Users** | 9 | Affects any user. | +| **Affected Users** | 10 | Affects any user. | | **Discoverability** | 7 | Easy to try for the attacker. | -**Average DREAD Score:** **7.2** +**Average DREAD Score:** **7.4** #### References @@ -504,7 +504,7 @@ failed proofs, the provider is removed from the contract, freeing the slot for a #### Scenario The `markProofAsMissing` function, along with related functions such as `fillSlot` and `requestStorage`, -makes external calls (e.g., `transferFrom`) before completing internal state updates. +makes external calls (e.g., `transfer`) before completing internal state updates. This opens the door to reentrancy attacks, where an attacker can re-enter the function and trigger multiple operations in a single transaction, such as slashing collateral multiple times or claiming validator rewards repeatedly. @@ -546,15 +546,15 @@ Use OpenZeppelin’s `ReentrancyGuard` to prevent nested entry into sensitive fu | **Damage Potential** | 8 | Can drain funds via multiple slashes and rewards. | | **Reproducibility** | 2 | Works consistently if reentrancy is not prevented. | | **Exploitability** | 2 | Requires contract-level knowledge and timing control. | -| **Affected Users** | 6 | Affects all contracts using `markProofAsMissing`. | +| **Affected Users** | 10 | Affects any user. | | **Discoverability** | 6 | Can be found through careful contract audit. | -**Average DREAD Score:** **4.8** +**Average DREAD Score:** **5** #### References -[Solidity](https://docs.soliditylang.org/en/latest/security-considerations.html#reentrancy) -[Checks-Effects-Interactions](https://docs.soliditylang.org/en/latest/security-considerations.html#use-the-checks-effects-interactions-pattern) +[Solidity](https://docs.soliditylang.org/en/latest/security-considerations.html#reentrancy) +[Checks-Effects-Interactions](https://docs.soliditylang.org/en/latest/security-considerations.html#use-the-checks-effects-interactions-pattern) [Reentrancy guard](https://docs.openzeppelin.com/contracts/4.x/api/security#ReentrancyGuard) ## Repudiation @@ -608,14 +608,14 @@ Fill Request 1 Slot 2 ╷ ╷ ─│── ───│ to fill Request 2 Slot 2 ╷ │ │ ▼ │ │ ┌────────────────────┐ - │ Clever host │╶╶╶╶╶╶╶╶╶╶╶╶╶╶▶ │Slot 1│Slot 2│Slot 3│ + │ Clever host │╶╶╶╶╶╶╶╶╶╶╶╶╶▶ │Slot 1│Slot 2│Slot 3│ │ │ └────────────────────┘ │ │ ─│── ───│ ────── ``` -Edit/view: https://cascii.app/93704 +Edit/view: https://cascii.app/9e208 #### Impacts @@ -625,11 +625,9 @@ Edit/view: https://cascii.app/93704 #### Mitigation This attack is mitigated by the storage provider losing its request collateral for the first -slot once it is abandoned. Additionally, after filling the first slot, the provider begins -to accrue rewards over time, but these rewards are only paid out if the request is -successfully completed. This delayed payout acts as an additional disincentive for the -storage provider to abandon the slot. -`` +slot once it is abandoned. Additionally, after filling the first slot, the rewards are only paid +out if the request is successfully completed. This delayed payout acts as an additional disincentive f +or the storage provider to abandon the slot. #### DREAD Score @@ -692,17 +690,17 @@ Other users could access this information, creating a privacy risk. │ │ │ │ │ │ ─│ ─│ ─│ ─│ ─│ ─│ ────── ────── ────── - ╷ ╷ ╷ - ╷ ╷ ╷ - ╷ ▼ ╷ - ╷ ┌──────────────────────┐ ╷ - ╷ │ │ ╷ - └╶╶╶╶╶╶▶ │ Original file │◀╶╶╶╶╶╶┘ + ╷ ╷ ╷ + ╷ ╷ ╷ + ╷ ▼ ╷ + ╷ ┌──────────────────────┐ ╷ + ╷ │ │ ╷ + └╶╶╶╶╶╶▶ │ Original file │ ◀╶╶╶╶╶╶┘ │ │ └──────────────────────┘ ``` -Edit/view: https://cascii.app/07f58 +Edit/view: https://cascii.app/7ff0e #### Impacts @@ -713,9 +711,9 @@ Edit/view: https://cascii.app/07f58 #### Mitigation -Encrypt files on the client side before upload to ensure that only authorized users -can decrypt and access the contents. In addition, sensitive metadata should be removed or -encrypted where possible to reduce the risk of privacy leaks. +Encrypt files to ensure that only authorized users can decrypt and access the contents. +In addition, sensitive metadata should be removed or encrypted where possible to reduce +the risk of privacy leaks. #### DREAD Score @@ -729,7 +727,7 @@ encrypted where possible to reduce the risk of privacy leaks. **Average DREAD Score:** **5.6** -[References] +References [Metadata = Surveillance](https://www.schneier.com/blog/archives/2014/03/metadata_survei.html?utm_source=chatgpt.com) @@ -743,7 +741,7 @@ blocking, or disrupting normal operations. #### Scenario In a single-reservation system, each slot is assigned to one storage provider through a 1-to-1 match. -A storage provider may reserve a slot but delay filling it, hoping a better opportunity will appear — +A storage provider may reserve a slot but delay filling it, hoping a better opportunity will appear, one that offers a higher reward than the original slot. ``` @@ -754,14 +752,14 @@ one that offers a higher reward than the original slot. │ │ │ │ ─│ ─│ ─│ ─│ ────── ────── - ╷ ╷ - ╷ ╷ - ╷ ╷ - ╷ ╷ - ╷ ╷ - ╷ ┌────────────────────┐ ╷ - ╷ │ │ ╷ - └╶╶╶╶╶╶╶╶╶╶╶╶╶╶▶│ Codex network │◀╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶┘ + ╷ ╷ + ╷ ╷ + ╷ ╷ + ╷ ╷ + ╷ ╷ + ╷ ┌────────────────────┐ ╷ + ╷ │ │ ╷ + └╶╶╶╶╶╶╶╶╶╶╶╶▶ │ Codex network │ ◀╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶┘ │ │ ┌╶╶╶╶╶╶╶╶╶╶╶└────────────────────┘╶╶╶╶╶╶╶╶╶╶╶╶┐ ╷ ╷ ╷ @@ -772,20 +770,20 @@ Request 1 ╷ ╷ ╷ Request 2 ┌────────────────────┐ ╷ ┌────────────────────┐ │Slot 1│Slot 2│Slot 3│ ╷ │Slot 1│Slot 2│Slot 3│ └────────────────────┘ ╷ └────────────────────┘ - ╷ ╷ ╷ - ╷ ╷ ╷ - ╷ ────── ╷ - ╷ ─│── ───│ ╷ - ╷ │ │ ╷ - ╷ │ │ ╷ - └╶╶╶╶╶╶╶╶╶╶╶╶▶│ Lazy host │◀╶╶╶╶╶╶╶╶╶╶╶╶╶╶┘ + ╷ ╷ ╷ + ╷ ╷ ╷ + ╷ ────── ╷ + ╷ ─│── ───│ ╷ + ╷ │ │ ╷ + ╷ │ │ ╷ + └╶╶╶╶╶╶╶╶╶╶╶▶ │ Lazy host │ ◀╶╶╶╶╶╶╶╶╶╶╶╶╶╶┘ │ │ Reserve Request 1 Slot 2 │ │ Reserve Request 2 Slot 2 ─│── ───│ ────── ``` -Edit/view: https://cascii.app/6144e +Edit/view: https://cascii.app/1f8a4 #### Impacts @@ -803,13 +801,13 @@ complete the request, ensuring reliability. | DREAD Component | Score | Description | | -------------------- | :---: | -------------------------------------------------------------- | -| **Damage Potential** | 7 | Fails storage requests, but no direct economic loss. | -| **Reproducibility** | 5 | Easy to repeat if system allows only single reservations. | +| **Damage Potential** | 7 | Fails storage requests. | +| **Reproducibility** | 8 | Easy to repeat if system allows only single reservations. | | **Exploitability** | 3 | Requires strategic delay by the storage provider. | | **Affected Users** | 4 | Affects users assigned to non-participating storage providers. | | **Discoverability** | 4 | Hard to detect until the storage deadline is missed. | -**Average DREAD Score:** **4.6** +**Average DREAD Score:** **5.2** ### Overload attack @@ -834,14 +832,14 @@ This overloads validators and delays their ability to detect missed proofs in ti ┌─────────────────────────────────┐ │R1│R2│R3│R4│R5│R5│R6│R7│R8│R9│R10│ └─────────────────────────────────┘ - ╷ ╷ ╷ ╷ ╷ ╷ ╷ ╷ ╷ ╷ │ - ╷ ╷ ╷ ╷ ╷ ╷ ╷ ╷ ╷ ╷ │ - ╷ ╷ └╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶┘ ╷ │ - ╷ ╷ ╷ ╷ │ - ╷ ╷ ▼ ╷ │ - ╷ └▶┌────────────────────◀┘ │ - ╷ │ │ │ - └╶╶╶▶│ Codex │◀───┘ + ╷ ╷ ╷ ╷ ╷ ╷ ╷ ╷ ╷ ╷ ╷ + ╷ ╷ ╷ ╷ ╷ ╷ ╷ ╷ ╷ ╷ ╷ + ╷ └╶╶└╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶┘╶╶┘ ╷ + ╷ ╷ ╷ + ╷ ▼ ╷ + ╷ ┌────────────────────┐ ╷ + ╷ │ │ ╷ + └╶▶ │ Codex │◀╶╶╶╶┘ │ │ └────────────────────┘ ╷ @@ -861,7 +859,7 @@ This overloads validators and delays their ability to detect missed proofs in ti Validators are too busy ``` -Edit/view: https://cascii.app/b6a31 +Edit/view: https://cascii.app/3af32 #### Impacts @@ -876,15 +874,15 @@ limiting the number of storage requests per IP address, and setting a minimum fi #### DREAD Score -#### DREAD Score: Overload Attack +#### DREAD Score -| DREAD Component | Score | Description | -| -------------------- | :---: | -------------------------------------------------------------- | -| **Damage Potential** | 8 | Temporarily weakens validation and file availability. | -| **Reproducibility** | 2 | Hard to repeat. | -| **Exploitability** | 2 | Requires ability to send many valid requests at scale. | -| **Affected Users** | 10 | Affects all users. | -| **Discoverability** | 4 | Noticeable during high load but hard to trace to one attacker. | +| DREAD Component | Score | Description | +| -------------------- | :---: | ------------------------------------------------------ | +| **Damage Potential** | 8 | Temporarily weakens validation and file availability. | +| **Reproducibility** | 2 | Hard to repeat. | +| **Exploitability** | 2 | Requires ability to send many valid requests at scale. | +| **Affected Users** | 10 | Affects all users. | +| **Discoverability** | 5 | Requires high activity. | **Average DREAD Score:** **5.2** @@ -954,7 +952,7 @@ This makes it economically unfeasible to sustain large-scale spamming. | **Reproducibility** | 2 | Possible but limited by transaction costs and network capacity. | | **Exploitability** | 2 | Requires funding. | | **Affected Users** | 8 | Affects most users during periods of slot disruption. | -| **Discoverability** | 3 | Hard to discover. | +| **Discoverability** | 3 | Requires high activity. | **Average DREAD Score:** **4.0** @@ -1021,45 +1019,37 @@ A storage provider attempts to fill multiple slots in the same storage request b multiple offers. This gives them a larger share of the deal, limiting participation by other providers. ``` - ────── - ─│ ─│ - │ │ - │ User │ - │ │ - ─│ ─│ - ────── - ╷ -Upload a file ╷ - ╷ - ▼ - ┌─────────────────┐ - │ │ - │ Codex │ - │ │ - └─────────────────┘ - ╷ - ╷ - ╷ - ╷ - ▼ - ┌────────────────────┐ - │Slot 1│Slot 2│Slot 3│ - └────────────────────┘ - ╷ ╷ ╷ - ╷ ╷ ╷ - └╶╶╶╶╶╶╷╶╶╶╶╶╶┘ - ╷ - ▼ - ────── - ─│ ─│ - │ │ - │ SP │ - │ │ - ─│ ─│ - ────── + ────── + ─│ ─│ + │ │ + │ User │ + │ │ + ─│ ─│ + ────── + ╷ + Upload a file ╷ + ╷ + ▼ + ┌─────────────────┐ + │ │ + │ Codex │◀╶╶╶╶╶╶╶╶╶╶╶╶╶╶┐ + │ │ ╷ + ╷─────────────────╷ ╷ + ╷ ╷ ╷ + ╷ ╷ Block the ╷ +Store the file ╷ ╷ content ╷ ────── + ╷ ╷ ┌───────────┐ ─│ ─│ + ╷ ────── ╷ │ │ │ │ + ╷ ─│ ─│ ╷ │ CID │◀╶╶╶╶╶╶╶╶│ User │ + ╷ │ │ ╷ │ │ │ │ + └▶ │ SP │◀╶┘ └───────────┘ ─│ ─│ + │ │ ────── + ─│ ─│ + ────── + ``` -Edit/view: https://cascii.app/f3984 +Edit/view: https://cascii.app/279c5 #### Impacts @@ -1077,7 +1067,7 @@ the request, the mechanism may be less effective, as fewer providers may be avai | DREAD Component | Score | Description | | -------------------- | :---: | ------------------------------------------------------------- | -| **Damage Potential** | 5 | Reduces fairness; may lead to centralization over time. | +| **Damage Potential** | 5 | Reduces fairness, may lead to centralization over time. | | **Reproducibility** | 6 | Easy to repeat with fast or automated submissions. | | **Exploitability** | 2 | Requires timing advantage or faster infrastructure. | | **Affected Users** | 6 | Affects any users sharing storage requests with greedy hosts. | @@ -1181,7 +1171,7 @@ deal terms in their favor and take control of the funds. Take control of the s ▼ mart contracts ┌───────────────────────────┐ │ │ - ┌╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶▶│ Smart contracts │ + ┌╶╶╶╶╶╶╶╶╶╶╶╶╶╶▶ │ Smart contracts │ ╷ │ │ ╷ ╷───────────────────────────┘ ╷ ╷ ▲ @@ -1211,7 +1201,7 @@ deal terms in their favor and take control of the funds. ────── ``` -Edit/view: https://cascii.app/23869 +Edit/view: https://cascii.app/4d5a6 #### Impacts From 67faeb42f7371646eaeaa0697ea1a9a531eacb51 Mon Sep 17 00:00:00 2001 From: Arnaud Date: Tue, 22 Apr 2025 21:24:34 +0200 Subject: [PATCH 13/14] Minor fixes --- evaluations/threat-modeling.md | 78 +++++++++++++++++++--------------- 1 file changed, 43 insertions(+), 35 deletions(-) diff --git a/evaluations/threat-modeling.md b/evaluations/threat-modeling.md index d3b3049..d5677e2 100644 --- a/evaluations/threat-modeling.md +++ b/evaluations/threat-modeling.md @@ -695,7 +695,7 @@ Other users could access this information, creating a privacy risk. ╷ ▼ ╷ ╷ ┌──────────────────────┐ ╷ ╷ │ │ ╷ - └╶╶╶╶╶╶▶ │ Original file │ ◀╶╶╶╶╶╶┘ + └╶╶╶╶╶╶▶ │ Original file │ ◀╶╶╶╶╶╶┘ │ │ └──────────────────────┘ ``` @@ -759,7 +759,7 @@ one that offers a higher reward than the original slot. ╷ ╷ ╷ ┌────────────────────┐ ╷ ╷ │ │ ╷ - └╶╶╶╶╶╶╶╶╶╶╶╶▶ │ Codex network │ ◀╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶┘ + └╶╶╶╶╶╶╶╶╶╶╶╶▶ │ Codex network │ ◀╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶┘ │ │ ┌╶╶╶╶╶╶╶╶╶╶╶└────────────────────┘╶╶╶╶╶╶╶╶╶╶╶╶┐ ╷ ╷ ╷ @@ -776,7 +776,7 @@ Request 1 ╷ ╷ ╷ Request 2 ╷ ─│── ───│ ╷ ╷ │ │ ╷ ╷ │ │ ╷ - └╶╶╶╶╶╶╶╶╶╶╶▶ │ Lazy host │ ◀╶╶╶╶╶╶╶╶╶╶╶╶╶╶┘ + └╶╶╶╶╶╶╶╶╶╶╶▶│ Lazy host │ ◀╶╶╶╶╶╶╶╶╶╶╶╶╶╶┘ │ │ Reserve Request 1 Slot 2 │ │ Reserve Request 2 Slot 2 ─│── ───│ @@ -839,7 +839,7 @@ This overloads validators and delays their ability to detect missed proofs in ti ╷ ▼ ╷ ╷ ┌────────────────────┐ ╷ ╷ │ │ ╷ - └╶▶ │ Codex │◀╶╶╶╶┘ + └╶▶ │ Codex │◀╶╶╶╶┘ │ │ └────────────────────┘ ╷ @@ -988,7 +988,7 @@ Store the file ╷ ╷ content ╷ ─ ╷ ────── ╷ │ │ │ │ ╷ ─│ ─│ ╷ │ CID │◀╶╶╶╶╶╶╶╶│ User │ ╷ │ │ ╷ │ │ │ │ - └╶▶│ SP │◀╶┘ └───────────┘ ─│ ─│ + └╶▶│ SP │◀╶┘ └───────────┘ ─│ ─│ │ │ ────── ─│ ─│ ────── @@ -1019,37 +1019,45 @@ A storage provider attempts to fill multiple slots in the same storage request b multiple offers. This gives them a larger share of the deal, limiting participation by other providers. ``` - ────── - ─│ ─│ - │ │ - │ User │ - │ │ - ─│ ─│ - ────── - ╷ - Upload a file ╷ - ╷ - ▼ - ┌─────────────────┐ - │ │ - │ Codex │◀╶╶╶╶╶╶╶╶╶╶╶╶╶╶┐ - │ │ ╷ - ╷─────────────────╷ ╷ - ╷ ╷ ╷ - ╷ ╷ Block the ╷ -Store the file ╷ ╷ content ╷ ────── - ╷ ╷ ┌───────────┐ ─│ ─│ - ╷ ────── ╷ │ │ │ │ - ╷ ─│ ─│ ╷ │ CID │◀╶╶╶╶╶╶╶╶│ User │ - ╷ │ │ ╷ │ │ │ │ - └▶ │ SP │◀╶┘ └───────────┘ ─│ ─│ - │ │ ────── - ─│ ─│ - ────── - + ────── + ─│ ─│ + │ │ + │ User │ + │ │ + ─│ ─│ + ────── + ╷ +Upload a file ╷ + ╷ + ▼ + ┌─────────────────┐ + │ │ + │ Codex │ + │ │ + └─────────────────┘ + ╷ + ╷ + ╷ + ╷ + ▼ + ┌────────────────────┐ + │Slot 1│Slot 2│Slot 3│ + └────────────────────┘ + ╷ ╷ ╷ + ╷ ╷ ╷ + └╶╶╶╶╶╶╷╶╶╶╶╶╶┘ + ╷ + ▼ + ────── + ─│ ─│ + │ │ + │ SP │ + │ │ + ─│ ─│ + ────── ``` -Edit/view: https://cascii.app/279c5 +Edit/view: https://cascii.app/f3984 #### Impacts @@ -1182,7 +1190,7 @@ deal terms in their favor and take control of the funds. ─│── ───│ ╷ ╷ │ │ ╷ ╷ │ │ ╷ ╷ -│ Attacker │◀╶╶╶╶╶╶╶┘ ╷ +│ Attacker │◀╶╶╶╶╶╶╶┘ ╷ │ │ ╷ │ │ Manipulates ╷ ─│── ───│ incoming storage ╷ From 8cf23f82fd43b172638f400288797b885d5e4183 Mon Sep 17 00:00:00 2001 From: Arnaud Date: Tue, 22 Apr 2025 21:26:13 +0200 Subject: [PATCH 14/14] Minor fix --- evaluations/threat-modeling.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/evaluations/threat-modeling.md b/evaluations/threat-modeling.md index d5677e2..aacb285 100644 --- a/evaluations/threat-modeling.md +++ b/evaluations/threat-modeling.md @@ -1179,7 +1179,7 @@ deal terms in their favor and take control of the funds. Take control of the s ▼ mart contracts ┌───────────────────────────┐ │ │ - ┌╶╶╶╶╶╶╶╶╶╶╶╶╶╶▶ │ Smart contracts │ + ┌╶╶╶╶╶╶╶╶╶╶╶╶╶╶▶│ Smart contracts │ ╷ │ │ ╷ ╷───────────────────────────┘ ╷ ╷ ▲