From 698e4754f0ec68afc5de05ea3b592f88fbc933f0 Mon Sep 17 00:00:00 2001 From: agusduha Date: Wed, 2 Apr 2025 18:26:49 -0300 Subject: [PATCH 1/6] feat: add interop access list FMA --- security/fma-interop-access-list.md | 121 ++++++++++++++++++++++++++++ 1 file changed, 121 insertions(+) create mode 100644 security/fma-interop-access-list.md diff --git a/security/fma-interop-access-list.md b/security/fma-interop-access-list.md new file mode 100644 index 00000000..3353ffb5 --- /dev/null +++ b/security/fma-interop-access-list.md @@ -0,0 +1,121 @@ +# Interop Access List: Failure Modes and Recovery Path Analysis + +| Author | Agusduha, Skeletor-spaceman | +| ------------------- | ---------------------------- | +| Created at | 2025-02-05 | +| Initial Reviewers | [Initial Reviewer Names] | +| Needs Approval From | Matt Solomon, Kelvin Fichter | +| Status | Draft | + +## Introduction + +This document covers the failure modes and recovery paths for the access list validation mechanism in cross-chain message processing. The access list enhancement aims to prevent denial of service (DoS) attacks and enable cheap pre-validation of cross-chain messages. + +The following components are included: + +- **Contracts**: + - Updates to `CrossL2Inbox`: Implements gas introspection to validate `ExecutingMessage` transactions + - Storage slot warming mechanism for message validation + - Checksum calculation and verification logic + +Below are references for this project: + +- Design PR: [Access List design](https://github.com/ethereum-optimism/design-docs/pull/214) +- Specs PR: [Access List Validation](https://github.com/ethereum-optimism/specs/pull/612) + +## Failure Modes and Recovery Paths + +### FM1: Gas Schedule Changes Break Validation + +- **Description:** The validation mechanism relies on gas introspection to determine if storage slots are warm. If the EVM's gas schedule changes, particularly around storage access costs, it could break the validation logic. +- **Risk Assessment:** High + - Potential Impact: Critical. Changes to gas costs could cause all cross-chain message validation to fail or allow invalid messages to pass. + - Likelihood: Low. While gas schedule changes are rare, they do occur during network upgrades. +- **Mitigations:** + - Set `WARM_READ_THRESHOLD` conservatively to account for potential fluctuations + - Add tests that verify validation works across different gas cost scenarios + - Document gas schedule dependencies clearly for future upgrades +- **Detection:** Monitor for network upgrades that modify storage access gas costs. Run validation tests before accepting upgrades. +- **Recovery Path(s):** Deploy contract upgrade with adjusted thresholds if gas schedule changes significantly. + +### FM2: Storage Slot Collision + +- **Description:** The checksum calculation for message validation uses storage slots that could potentially collide with other slots from the access list, leading to false validation of messages. +- **Risk Assessment:** High + - Potential Impact: Critical. Storage collisions could allow unauthorized messages to be validated. + - Likelihood: Low. Storage slots are carefully calculated using Identifier and message hash parameter. The way both are encoded in the contract’s logic needs to be flawed for this case to happen. +- **Mitigations** + - Implement robust checksum calculation that minimizes collision risk + - Add tests verifying no collisions occur with expected storage patterns + - Document storage layout and slot calculation methodology +- **Detection:** Monitor for unexpected message validations that could indicate storage collisions. +- **Recovery Path(s):** Deploy contract upgrade with revised storage slot calculation if collisions are detected and update ALL off-chain tools and SDKs that generate these hashes on the access list. + +### FM3: Access List Manipulation + +- **Description:** Malicious actors could attempt to manipulate transaction access lists to force validation of unauthorized messages. +- **Risk Assessment:** High + - Potential Impact: High. Could allow unauthorized message execution. + - Likelihood: Medium. Access lists are user-controlled transaction parameters. +- **Mitigations:** + - Ensure checksum calculation is cryptographically sound + - Implement proper validation of access list entries + - Add checks for maximum access list size +- **Detection:** Monitor for unusual patterns in access list usage and message validation attempts. +- **Recovery Path(s):** Pause message processing if manipulation is detected. Deploy fixes for validation logic. + +### FM4: Relayer Implementation Errors + +- **Description:** Relayers may implement access list construction incorrectly, leading to failed message validation even for valid messages. One possible cause for this could be the checksum calculation not matching between clients and on-chain logic. +- **Risk Assessment:** Medium + - Potential Impact: Medium. Could cause temporary disruption of cross-chain messaging. + - Likelihood: Medium. Relayers need to adopt new patterns for access list construction. +- **Mitigations:** + - Provide clear documentation and examples for relayer implementations + - Create reference implementations and test suites + - Add monitoring for failed validation attempts +- **Detection:** Track validation failure rates and patterns across relayers. +- **Recovery Path(s):** Work with relayer implementations to fix access list construction. + +### FM5: Compiler Optimizations Break Gas Introspection + +- **Description:** Future changes in the Solidity compiler, via-IR pipeline, or optimizer settings could eliminate or modify the `SLOAD` operation used for gas introspection. This could cause the contract to incorrectly determine that a cold storage slot is warm, as the gas cost check would be optimized away. +- **Risk Assessment:** High + - Potential Impact: Critical. Could allow validation of unauthorized messages by bypassing the access list check entirely. + - Likelihood: Medium. Compiler optimizations regularly evolve and could unexpectedly affect low-level gas introspection. +- **Mitigations:** + - Lock compiler version and optimization settings + - Document compiler dependencies and optimization constraints +- **Detection:** + - Regular bytecode verification to ensure `SLOAD` operations remain in place + - Test suite that verifies gas costs match expectations +- **Recovery Path(s):** + - Deploy contract upgrade with revised gas introspection implementation that cannot be optimized away + - Roll back to previous compiler version if optimization cannot be disabled + +### Generic items we need to take into account: + +See [fma-generic-contracts.md](https://github.com/ethereum-optimism/design-docs/blob/main/security/fma-generic-contracts.md). + +- [x] Check this box to confirm that these items have been considered and updated if necessary. + +## Action Items + +- [ ] FM1: Implement comprehensive gas schedule testing +- [ ] FM1: Document gas schedule dependencies +- [ ] FM2: Create storage layout documentation +- [ ] FM2: Implement slots collision tests +- [ ] FM3: Add access list validation tests +- [ ] FM3: Document security considerations for access list handling +- [ ] FM4: Create relayer implementation guide +- [ ] FM4: Develop relayer test suite +- [ ] FM5: Document compiler version and optimization constraints + +## Audit Requirements + +The access list validation mechanism in `CrossL2Inbox` requires an audit before production deployment, with particular focus on: + +- Gas introspection implementation +- Storage slot calculation and collision resistance +- Access list validation logic +- Integration with existing message passing system From 073c7d85b83ca2a0275842f929b602276280592b Mon Sep 17 00:00:00 2001 From: agusduha Date: Fri, 4 Apr 2025 10:04:10 -0300 Subject: [PATCH 2/6] fix: merge FM1 and FM5, remove FM3 and FM4 --- security/fma-interop-access-list.md | 75 ++++++++--------------------- 1 file changed, 19 insertions(+), 56 deletions(-) diff --git a/security/fma-interop-access-list.md b/security/fma-interop-access-list.md index 3353ffb5..27efb127 100644 --- a/security/fma-interop-access-list.md +++ b/security/fma-interop-access-list.md @@ -21,29 +21,39 @@ The following components are included: Below are references for this project: - Design PR: [Access List design](https://github.com/ethereum-optimism/design-docs/pull/214) -- Specs PR: [Access List Validation](https://github.com/ethereum-optimism/specs/pull/612) +- Specs PR: [Access List spec](https://github.com/ethereum-optimism/specs/pull/612) ## Failure Modes and Recovery Paths -### FM1: Gas Schedule Changes Break Validation +### FM1: Gas Introspection Breaks Due to EVM Changes or Compiler Optimizations -- **Description:** The validation mechanism relies on gas introspection to determine if storage slots are warm. If the EVM's gas schedule changes, particularly around storage access costs, it could break the validation logic. +- **Description:** The validation mechanism relies on gas introspection to determine if storage slots are warm. This can break in two ways: + 1. If the EVM's gas schedule changes, particularly around storage access costs, it could break the validation logic + 2. Future changes in the Solidity compiler, via-IR pipeline, or optimizer settings could eliminate or modify the `SLOAD` operation used for gas introspection, causing the contract to incorrectly determine that a cold storage slot is warm - **Risk Assessment:** High - - Potential Impact: Critical. Changes to gas costs could cause all cross-chain message validation to fail or allow invalid messages to pass. - - Likelihood: Low. While gas schedule changes are rare, they do occur during network upgrades. + - Potential Impact: Critical. Changes to gas costs or optimized-away operations could cause all cross-chain message validation to fail or allow invalid messages to pass. + - Likelihood: Medium. While gas schedule changes are rare, they do occur during network upgrades. Additionally, compiler optimizations regularly evolve and could unexpectedly affect low-level gas introspection. - **Mitigations:** - Set `WARM_READ_THRESHOLD` conservatively to account for potential fluctuations + - Lock compiler version and optimization settings + - Document compiler dependencies, optimization constraints, and gas schedule dependencies - Add tests that verify validation works across different gas cost scenarios - - Document gas schedule dependencies clearly for future upgrades -- **Detection:** Monitor for network upgrades that modify storage access gas costs. Run validation tests before accepting upgrades. -- **Recovery Path(s):** Deploy contract upgrade with adjusted thresholds if gas schedule changes significantly. + - Regular bytecode verification to ensure `SLOAD` operations remain in place +- **Detection:** + - Monitor for network upgrades that modify storage access gas costs + - Regular bytecode verification to ensure `SLOAD` operations remain in place + - Test suite that verifies gas costs match expectations + - Run validation tests before accepting upgrades +- **Recovery Path(s):** + - Deploy contract upgrade with adjusted thresholds if gas schedule changes significantly + - Roll back to previous compiler version if optimization cannot be disabled ### FM2: Storage Slot Collision - **Description:** The checksum calculation for message validation uses storage slots that could potentially collide with other slots from the access list, leading to false validation of messages. - **Risk Assessment:** High - Potential Impact: Critical. Storage collisions could allow unauthorized messages to be validated. - - Likelihood: Low. Storage slots are carefully calculated using Identifier and message hash parameter. The way both are encoded in the contract’s logic needs to be flawed for this case to happen. + - Likelihood: Low. Storage slots are carefully calculated using Identifier and message hash parameter. The way both are encoded in the contract's logic needs to be flawed for this case to happen. - **Mitigations** - Implement robust checksum calculation that minimizes collision risk - Add tests verifying no collisions occur with expected storage patterns @@ -51,48 +61,6 @@ Below are references for this project: - **Detection:** Monitor for unexpected message validations that could indicate storage collisions. - **Recovery Path(s):** Deploy contract upgrade with revised storage slot calculation if collisions are detected and update ALL off-chain tools and SDKs that generate these hashes on the access list. -### FM3: Access List Manipulation - -- **Description:** Malicious actors could attempt to manipulate transaction access lists to force validation of unauthorized messages. -- **Risk Assessment:** High - - Potential Impact: High. Could allow unauthorized message execution. - - Likelihood: Medium. Access lists are user-controlled transaction parameters. -- **Mitigations:** - - Ensure checksum calculation is cryptographically sound - - Implement proper validation of access list entries - - Add checks for maximum access list size -- **Detection:** Monitor for unusual patterns in access list usage and message validation attempts. -- **Recovery Path(s):** Pause message processing if manipulation is detected. Deploy fixes for validation logic. - -### FM4: Relayer Implementation Errors - -- **Description:** Relayers may implement access list construction incorrectly, leading to failed message validation even for valid messages. One possible cause for this could be the checksum calculation not matching between clients and on-chain logic. -- **Risk Assessment:** Medium - - Potential Impact: Medium. Could cause temporary disruption of cross-chain messaging. - - Likelihood: Medium. Relayers need to adopt new patterns for access list construction. -- **Mitigations:** - - Provide clear documentation and examples for relayer implementations - - Create reference implementations and test suites - - Add monitoring for failed validation attempts -- **Detection:** Track validation failure rates and patterns across relayers. -- **Recovery Path(s):** Work with relayer implementations to fix access list construction. - -### FM5: Compiler Optimizations Break Gas Introspection - -- **Description:** Future changes in the Solidity compiler, via-IR pipeline, or optimizer settings could eliminate or modify the `SLOAD` operation used for gas introspection. This could cause the contract to incorrectly determine that a cold storage slot is warm, as the gas cost check would be optimized away. -- **Risk Assessment:** High - - Potential Impact: Critical. Could allow validation of unauthorized messages by bypassing the access list check entirely. - - Likelihood: Medium. Compiler optimizations regularly evolve and could unexpectedly affect low-level gas introspection. -- **Mitigations:** - - Lock compiler version and optimization settings - - Document compiler dependencies and optimization constraints -- **Detection:** - - Regular bytecode verification to ensure `SLOAD` operations remain in place - - Test suite that verifies gas costs match expectations -- **Recovery Path(s):** - - Deploy contract upgrade with revised gas introspection implementation that cannot be optimized away - - Roll back to previous compiler version if optimization cannot be disabled - ### Generic items we need to take into account: See [fma-generic-contracts.md](https://github.com/ethereum-optimism/design-docs/blob/main/security/fma-generic-contracts.md). @@ -105,11 +73,6 @@ See [fma-generic-contracts.md](https://github.com/ethereum-optimism/design-docs/ - [ ] FM1: Document gas schedule dependencies - [ ] FM2: Create storage layout documentation - [ ] FM2: Implement slots collision tests -- [ ] FM3: Add access list validation tests -- [ ] FM3: Document security considerations for access list handling -- [ ] FM4: Create relayer implementation guide -- [ ] FM4: Develop relayer test suite -- [ ] FM5: Document compiler version and optimization constraints ## Audit Requirements From 344a3a03d009ed2d77fc859665176390e7f06145 Mon Sep 17 00:00:00 2001 From: agusduha Date: Fri, 4 Apr 2025 11:25:28 -0300 Subject: [PATCH 3/6] feat: add new unexpected storage warming FM --- security/fma-interop-access-list.md | 31 +++++++++++++++++++++++++---- 1 file changed, 27 insertions(+), 4 deletions(-) diff --git a/security/fma-interop-access-list.md b/security/fma-interop-access-list.md index 27efb127..16c1b726 100644 --- a/security/fma-interop-access-list.md +++ b/security/fma-interop-access-list.md @@ -37,12 +37,12 @@ Below are references for this project: - Set `WARM_READ_THRESHOLD` conservatively to account for potential fluctuations - Lock compiler version and optimization settings - Document compiler dependencies, optimization constraints, and gas schedule dependencies - - Add tests that verify validation works across different gas cost scenarios + - Implement end-to-end tests that verify validation reverts work correctly in a real environment - Regular bytecode verification to ensure `SLOAD` operations remain in place - **Detection:** - Monitor for network upgrades that modify storage access gas costs - Regular bytecode verification to ensure `SLOAD` operations remain in place - - Test suite that verifies gas costs match expectations + - End-to-end test suite that verifies validation reverts as expected - Run validation tests before accepting upgrades - **Recovery Path(s):** - Deploy contract upgrade with adjusted thresholds if gas schedule changes significantly @@ -52,8 +52,8 @@ Below are references for this project: - **Description:** The checksum calculation for message validation uses storage slots that could potentially collide with other slots from the access list, leading to false validation of messages. - **Risk Assessment:** High - - Potential Impact: Critical. Storage collisions could allow unauthorized messages to be validated. - - Likelihood: Low. Storage slots are carefully calculated using Identifier and message hash parameter. The way both are encoded in the contract's logic needs to be flawed for this case to happen. + - Potential Impact: Critical. Storage collisions could allow unauthorized messages to be validated. Additionally, this would break the ability to filter invalid executing messages at ingress, creating a spam vector where MEV searchers could attempt arbitrage by submitting invalid messages with no inclusion cost. + - Likelihood: Extremely Low. Storage slots are calculated using a 248-bit (31 byte) hash space, providing cryptographically secure collision resistance. A collision would require finding a hash collision, which is computationally infeasible with 248 bits of security. - **Mitigations** - Implement robust checksum calculation that minimizes collision risk - Add tests verifying no collisions occur with expected storage patterns @@ -61,6 +61,27 @@ Below are references for this project: - **Detection:** Monitor for unexpected message validations that could indicate storage collisions. - **Recovery Path(s):** Deploy contract upgrade with revised storage slot calculation if collisions are detected and update ALL off-chain tools and SDKs that generate these hashes on the access list. +### FM3: Unexpected Storage Slot Warming Behavior + +- **Description:** The validation mechanism assumes that storage slots are only warmed through the transaction's access list and that warming is rolled back on revert. However, this behavior relies on EVM implementation details that aren't explicitly guaranteed by the protocol. Several potential issues arise: + 1. A slot could be warmed through other means than the access list + 2. The current behavior where slot warming is rolled back on revert isn't guaranteed by the protocol spec - it's an implementation detail that could change, as cached values theoretically could persist after reverts + 3. Storage warming is currently scoped per transaction, but future EVM updates could change this to be per block, which would break the security assumption that each transaction's access list independently controls its warm slots +- **Risk Assessment:** High + - Potential Impact: Critical. If slots remain warm after reverts, can be warmed through alternative means, or warming persists across transactions in a block, it could allow unauthorized messages to be validated, bypassing the access list requirement entirely. + - Likelihood: Low. While the current behavior is stable, it relies on implementation details rather than protocol guarantees. +- **Mitigations:** + - Document reliance on EVM warming behavior in reverts + - Add tests specifically verifying slot cooling behavior after reverts across multiple EVM clients + - Document dependency on per-transaction warming scope + - Monitor EIP proposals that could affect storage warming mechanics +- **Detection:** + - Regular testing of slot warming behavior across multiple EVM clients, especially after network upgrades + - Monitor for unexpected successful message validations + - Track EVM changes that could affect storage slot warming mechanics or scope + - Test that warm slots from previous transactions in a block don't affect current transaction +- **Recovery Path(s):** Deploy contract upgrade with alternative validation mechanism if EVM warming behavior changes + ### Generic items we need to take into account: See [fma-generic-contracts.md](https://github.com/ethereum-optimism/design-docs/blob/main/security/fma-generic-contracts.md). @@ -73,6 +94,8 @@ See [fma-generic-contracts.md](https://github.com/ethereum-optimism/design-docs/ - [ ] FM1: Document gas schedule dependencies - [ ] FM2: Create storage layout documentation - [ ] FM2: Implement slots collision tests +- [ ] FM3: Document EVM warming behavior dependencies and transaction-scoped assumptions +- [ ] FM3: Implement comprehensive slot warming behavior tests including multi-transaction tests ## Audit Requirements From f82e5e625a7ddea1e1fdcbaeb66f8f797919bc51 Mon Sep 17 00:00:00 2001 From: agusduha Date: Fri, 4 Apr 2025 16:16:39 -0300 Subject: [PATCH 4/6] fix: add initial reviewer --- security/fma-interop-access-list.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/security/fma-interop-access-list.md b/security/fma-interop-access-list.md index 16c1b726..0255215b 100644 --- a/security/fma-interop-access-list.md +++ b/security/fma-interop-access-list.md @@ -3,7 +3,7 @@ | Author | Agusduha, Skeletor-spaceman | | ------------------- | ---------------------------- | | Created at | 2025-02-05 | -| Initial Reviewers | [Initial Reviewer Names] | +| Initial Reviewers | Mark Tyneway | | Needs Approval From | Matt Solomon, Kelvin Fichter | | Status | Draft | @@ -90,8 +90,8 @@ See [fma-generic-contracts.md](https://github.com/ethereum-optimism/design-docs/ ## Action Items -- [ ] FM1: Implement comprehensive gas schedule testing - [ ] FM1: Document gas schedule dependencies +- [ ] FM1: Implement comprehensive gas schedule testing - [ ] FM2: Create storage layout documentation - [ ] FM2: Implement slots collision tests - [ ] FM3: Document EVM warming behavior dependencies and transaction-scoped assumptions From 42eefed43e4a63585af99078cdc69cde8ebf63f0 Mon Sep 17 00:00:00 2001 From: agusduha Date: Fri, 4 Apr 2025 16:21:19 -0300 Subject: [PATCH 5/6] fix: FM2 --- security/fma-interop-access-list.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/security/fma-interop-access-list.md b/security/fma-interop-access-list.md index 0255215b..cb3cdee2 100644 --- a/security/fma-interop-access-list.md +++ b/security/fma-interop-access-list.md @@ -53,7 +53,7 @@ Below are references for this project: - **Description:** The checksum calculation for message validation uses storage slots that could potentially collide with other slots from the access list, leading to false validation of messages. - **Risk Assessment:** High - Potential Impact: Critical. Storage collisions could allow unauthorized messages to be validated. Additionally, this would break the ability to filter invalid executing messages at ingress, creating a spam vector where MEV searchers could attempt arbitrage by submitting invalid messages with no inclusion cost. - - Likelihood: Extremely Low. Storage slots are calculated using a 248-bit (31 byte) hash space, providing cryptographically secure collision resistance. A collision would require finding a hash collision, which is computationally infeasible with 248 bits of security. + - Likelihood: Extremely Low. Storage slots are calculated using a 248-bit (31 byte) hash space, providing cryptographically secure collision resistance. A collision would require finding a hash collision, which makes it infeasible to have a collision as long as the implementation is correct. - **Mitigations** - Implement robust checksum calculation that minimizes collision risk - Add tests verifying no collisions occur with expected storage patterns From eceb66a4a36b4c9f55f27b24e6fc7a5a11c067f3 Mon Sep 17 00:00:00 2001 From: AgusDuha <81362284+agusduha@users.noreply.github.com> Date: Fri, 11 Apr 2025 11:35:37 -0300 Subject: [PATCH 6/6] fix: change status Co-authored-by: Matt Solomon --- security/fma-interop-access-list.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/security/fma-interop-access-list.md b/security/fma-interop-access-list.md index cb3cdee2..3109cea5 100644 --- a/security/fma-interop-access-list.md +++ b/security/fma-interop-access-list.md @@ -5,7 +5,7 @@ | Created at | 2025-02-05 | | Initial Reviewers | Mark Tyneway | | Needs Approval From | Matt Solomon, Kelvin Fichter | -| Status | Draft | +| Status | Implementing Actions | ## Introduction