GHSA-84xq-3662-pvx5: Transaction::from_json holds an input txid that is not 64 hex digits and writes the input as spending the zero txid
Transaction::fromjson, for a document with no hex member, held each input's txid member as given. An input txid that is not 64 hex digits ("zz", "", 63 or 65 digits, characters that are not hex digits) answered Ok: sourcetxid and tojson gave the text back, while tobinary wrote the input as spending the txid of 32 zero bytes and id() hashed those bytes. Documents naming different texts were one transaction, spending an outpoint none of them named.
An application that reads a peer's transaction document with fromjson and relies both on the text of its inputs and on its bytes or id() is affected; one that reads only documents it produced is not.
0.8.6 refuses such a txid (Invalid txid of input N: expected 64 hex digits). Where upgrading is not possible, require each input's txid to be 64 ASCII hex digits before calling fromjson.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
rust/bsv-rsto a version that resolves this vulnerability.Fixed in 0.8.6 - Upgrade
Upgrade
rust/bsv-rsto a version that resolves this vulnerability.Fixed in 0.9.0-beta.7.0 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 0.8.6 - Compensating control
Where upgrading is not possible, require each input's txid to be exactly 64 ASCII hexadecimal digits before calling from_json.
Event History
Frequently Asked Questions
Which applications are affected in practice?
Applications that parse transaction documents received from peers with `Transaction::from_json` and rely on both the textual input txids and the serialized bytes or `id()` are affected. Applications that only parse documents they produced are not affected.
What input is needed to trigger the issue?
An attacker only needs to supply a transaction document without a `hex` member containing an input `txid` that is not exactly 64 ASCII hexadecimal digits. Examples include an empty value, non-hex characters, or a txid with 63 or 65 digits.
What happens when an invalid txid is processed?
The textual txid is retained and returned by `source_txid` and `to_json`, but `to_binary` serializes that input using a 32-byte zero txid. The transaction `id()` is calculated over those serialized zero bytes, so documents with different invalid txid text can resolve to the same transaction and spend an outpoint not named in the document.
How can this be mitigated without upgrading?
Validate every input `txid` before calling `from_json`. Require it to be exactly 64 ASCII hexadecimal digits.
Which version rejects malformed input txids?
Version 0.8.6 rejects malformed input txids with an error indicating that the input txid must contain 64 hexadecimal digits.