A malicious slot leader can drop signatures

[garious]

Problem

A malicious slot leader could drop all but the first transaction signatures, causing the first signer to pay the transaction fee, but then see the program reject it because of missing signatures.

Proposed Solution

sigverify should reject transactions when there is a mismatch between tx.signatures.len() and tx.message().num_required_signatures.

tag: @sakridge

[aeyakovenko]

@garious how is the first signature valid? Each signature signs the entire transaction, which includes all the public keys, and if each key requires a signature.

[garious]

The signer can't sign the entire transaction, because that'd include the signature, which doesn't exist yet. It also doesn't sign the length of the signatures vector. Instead, it signs the whole Message struct, which includes a num_required_signatures. Ideally, that serialized data would be first in the serialized transaction, but instead it's placed after the signatures vector. Therefore, the signatures length is encoded in two places (each consuming 1 byte) and they have the same value. Only the first one is used by sigverify and that data is unsigned and can be modified by an attacker.

[aeyakovenko]

@garious The signer signs the list of pubkeys, and which are expected to provide a signature, as well as the message. The signatures are appended after. The transaction should be rejected as invalid before payment if any of the signatures fail the check.

[garious]

The signer signs a list of pubkeys which includes some which need a corresponding signature and some that don't. If the attacker reduces the number in the first byte of the transaction, then sigverify will successfully verify fewer signatures than the number in Message::num_required_signatures.

[aeyakovenko]

@garious, the signature covers all the pubkeys, including the signers as well as the num required.

[garious]

But sigverify uses the first byte (unsigned) to determine how many signatures to verify, not Message::num_required_signatures, which is signed.

[aeyakovenko]

Reducing the required number changes the message hash and breaks all the signatures. So a leader can’t do that.

A malicious drone can’t change the number either, because it breaks some of the signatures and the entire TX is marked as failed.

[aeyakovenko]

@garious, that’s funny. I guess we just need to check it’s the same value in tx.verify

[mvines]

Fixed