Transaction logs can be tampered with to reset rate limits #66

New Issue

Skipper · 2026-04-05T16:23:08Z

Skipper commented

2026-04-05 16:23:08 +00:00

Info

Severity: LOW
Attack vector: offline

Impact

Allows an attacker with database write access to reset rate-limit counters and restore spending capacity.

Description

evm_transaction_log and evm_token_transfer_log are not integrity-protected even though rate and volume checks rely on them to count prior activity. Deleting rows silently reduces the observed historical usage.

Example flow

Open the SQLite database offline.
Delete rows from evm_transaction_log or evm_token_transfer_log.
Submit new signing requests.
Pass rate-limit checks because prior usage has been erased.

Mitigation

Protect log records with integrity metadata or move the counters into a tamper-evident store.

# Info **Severity**: **LOW** Attack vector: offline ## Impact Allows an attacker with database write access to reset rate-limit counters and restore spending capacity. ## Description `evm_transaction_log` and `evm_token_transfer_log` are not integrity-protected even though rate and volume checks rely on them to count prior activity. Deleting rows silently reduces the observed historical usage. ## Example flow 1. Open the SQLite database offline. 2. Delete rows from `evm_transaction_log` or `evm_token_transfer_log`. 3. Submit new signing requests. 4. Pass rate-limit checks because prior usage has been erased. ## Mitigation Protect log records with integrity metadata or move the counters into a tamper-evident store.

CleverWild commented

2026-06-22 13:04:47 +00:00

A key limitation of the system: sign_entity and verify_entity protect against modification of existing entries, but not against their deletion. If an attacker deletes an entry from evm_transaction_log and its corresponding integrity_envelope, the rate-limit request simply counts one fewer entry without generating an error.

We need a signed cumulative counter for the grant: every time a transaction is added, we atomically update the signed counter, and during a rate-limit check, we compare COUNT(*) with the signed value. A discrepancy = proof of deletion. But it requires an aditional DB-Table with integrity_envelope.

A key limitation of the system: `sign_entity` and `verify_entity` protect against modification of existing entries, but not against their deletion. If an attacker deletes an entry from `evm_transaction_log` and its corresponding `integrity_envelope`, the rate-limit request simply counts one fewer entry without generating an error. We need a signed cumulative counter for the grant: every time a transaction is added, we atomically update the signed counter, and during a rate-limit check, we compare COUNT(*) with the signed value. A discrepancy = proof of deletion. But it requires an aditional DB-Table with `integrity_envelope`.

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: MarketTakers/arbiter#66