EVM: contract-call data display shows only the first chunk of what is signed

[BitHighlander]

Summary

Signing an arbitrary contract call displays only the first chunk of the payload, while the signature covers all of it.

lib/firmware/ethereum.c, in ethereum_signing_init():

layoutEthereumData(msg->data_initial_chunk.bytes,
                   msg->data_initial_chunk.size, data_total,
                   confirm_body_message, sizeof(confirm_body_message));
if (!confirm(ButtonRequestType_ButtonRequest_ConfirmOutput,
             "Confirm Ethereum Data", "%s", confirm_body_message)) {

data_total may be far larger than data_initial_chunk.size (the remainder streams in via EthereumTxAck), and confirm_body_message is a fixed char[121]. The user approves a window onto the payload and signs the whole thing.

There is a blind-signing warning first (suppressed once AdvancedMode is enabled), so this is disclosed rather than hidden — but the warning is generic and the displayed data is not what is signed.

Relationship to other work

#393 converted several sites to confirm_bytes(), which pages every byte of a length-delimited payload (Bitcoin/Ethereum SignMessage, both VerifyMessage paths, the SignIdentity challenge). This site was not converted, because the payload is streamed rather than held in one buffer — paging it requires buffering or incremental display, which is a design question rather than a mechanical substitution.

Acceptance criteria

• Decide the intended UX for a payload larger than the device can display
• Either page the full payload, or show a cryptographic commitment (e.g. keccak of the full data) the user can compare against the host
• Do not rely on the AdvancedMode warning as the only mitigation

[BitHighlander]

Interaction with #413, which is landing in 7.14.2 (PR #418).

#413 fixes a different site — the contract decoders (zxswap, thortx, zxtransERC20, saproxy, zxliquidtx, zxappliquid) claimed a transaction, discarded data_total, and narrated a clear-sign screen while the streamed remainder was hashed unreviewed. The fix adds a single guard in ethereum_contractHandled():

if (data_total != msg->data_initial_chunk.size) return false;

so an oversized payload is no longer claimed by a decoder.

That makes this issue more important, not less. Refusing to clear-sign routes those transactions to exactly the generic path described here — the AdvancedMode warning followed by layoutEthereumData() and the "Confirm Ethereum Data" screen. So after 7.14.2, more traffic lands on a screen that still shows only the first chunk of what is signed.

This is still a strict improvement: a truncated-but-generic disclosure behind a real confirm() gate beats a confident clear-sign narration of calldata the device never saw. But it is a mitigation, not a fix, and this issue remains the actual fix.

Leaving the 7.15.0 milestone. The acceptance criteria here — page the full payload, or display a cryptographic commitment the user can compare against the host — are a UX and buffering design question, not a mechanical change, and deliberately out of scope for a minimal security release.

[BitHighlander]

Remediation is under review in firmware PR #587 (d27a6846) with its end-to-end regression in BitHighlander/python-keepkey#59 (d8f06982). Firmware incrementally commits every calldata chunk to Keccak-256 and discloses the final digest before signing; the test holds the entire first 1,024 bytes and length constant, changes only the final ack byte, recovers both signatures over the complete payloads, and requires different visible frame sequences. Both PRs remain unmerged pending the full clean-volume Docker gate and CI.