harden: typed-data signing shows no warning for allowance-granting shapes and displays a primaryType it does not enforce #400

New Issue

2026-09-21T20:37:56+02:00

clawbot commented

2026-09-21 20:37:56 +02:00

Severity: hardening (mitigates the dominant signature-drain attack class).

Where. src/popup/views/approval.js:383-415 (formatTypedDataHtml) and
814-822 (typed-data signing).

What is wrong. formatTypedDataHtml prints domain, primaryType and the
top-level message keys as neutral key/value lines, so an EIP-2612 Permit or a
Permit2 PermitSingle/PermitBatch — the standard token-drain signature — is
presented exactly like a login message, with no highlight of the spender, the
amount, or the deadline. Separately, the screen prints the page-supplied
primaryType, but ethers derives the primary type from the types graph when
signing, so the name shown need not be the type actually signed.

Why it matters. Signature-based approvals (Permit, Permit2) are the dominant
dApp drain vector; the prompt does nothing to distinguish a drain from a login.

Reproduction. A connected page requests eth_signTypedData_v4 with a Permit2
PermitSingle granting an attacker spender an unlimited allowance; the prompt
shows "Typed data (EIP-712)" and plain key/value lines, with no warning.

Acceptable. Recognise the common allowance shapes (Permit, Permit2) and show
a prominent warning naming the spender and amount; refuse or flag the request
when the supplied primaryType is absent or does not match the type ethers will
sign.

Definition of done.

The typed-data screen shows a distinct warning for recognised
allowance/permit shapes, naming the spender and the amount.
The primary type displayed is the one ethers signs, or the request is
refused when they differ.
Tests assert the warning appears for a Permit2 PermitSingle and not for
an ordinary login message.

Model: fable-5-1 (review); opus-4-8 (filing)

Severity: hardening (mitigates the dominant signature-drain attack class). **Where.** `src/popup/views/approval.js:383-415` (`formatTypedDataHtml`) and `814-822` (typed-data signing). **What is wrong.** `formatTypedDataHtml` prints `domain`, `primaryType` and the top-level `message` keys as neutral key/value lines, so an EIP-2612 Permit or a Permit2 `PermitSingle`/`PermitBatch` — the standard token-drain signature — is presented exactly like a login message, with no highlight of the spender, the amount, or the deadline. Separately, the screen prints the page-supplied `primaryType`, but ethers derives the primary type from the `types` graph when signing, so the name shown need not be the type actually signed. **Why it matters.** Signature-based approvals (Permit, Permit2) are the dominant dApp drain vector; the prompt does nothing to distinguish a drain from a login. **Reproduction.** A connected page requests `eth_signTypedData_v4` with a Permit2 `PermitSingle` granting an attacker spender an unlimited allowance; the prompt shows "Typed data (EIP-712)" and plain key/value lines, with no warning. **Acceptable.** Recognise the common allowance shapes (Permit, Permit2) and show a prominent warning naming the spender and amount; refuse or flag the request when the supplied `primaryType` is absent or does not match the type ethers will sign. **Definition of done.** - [ ] The typed-data screen shows a distinct warning for recognised allowance/permit shapes, naming the spender and the amount. - [ ] The primary type displayed is the one ethers signs, or the request is refused when they differ. - [ ] Tests assert the warning appears for a Permit2 `PermitSingle` and not for an ordinary login message. Model: fable-5-1 (review); opus-4-8 (filing)

clawbot added this to the 1.0.0 milestone 2026-09-21 20:37:56 +02:00

clawbot referenced this issue

2026-09-21 20:39:01 +02:00

security: pre-1.0 review of key handling, DEBUG mode and RPC/dApp input validation #383

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/AutistMask#400