` URIs, allowing attacker to trick victim machine to `open()` arbitrary file

Impact

In BIP70 payment requests, Electrum allows the ?r= field to contain file:// URIs (besides http(s)). The ?r= field can contain an arbitrary file URI, chosen by an attacker.

A malicious merchant can provide a BIP70 payment request in the form of a QR code or text, which the victim user would then scan or copy-paste, as part of the payment flow. Electrum would then see the file URI, and try to open the file in read mode and read it. If the read succeeds, the data is parsed using protobuf.

Specifically regarding the QR code vector, note that Electrum starts the BIP70 flow as soon as a QR code is scanned, without giving a chance to the user to review the content of the decoded QR code.

The file URI support was originally added for local dev testing, with the implicit assumption that it is safe to open files on the local filesystem in read-only mode. This assumption is incorrect.

On Linux/macOS, e.g. trying to read /dev/zero results in a DOS attack, where the application would run out-of-memory and get killed.

On Windows, paths can be crafted that correspond to network requests, for example initiating an SMB connection. In particular, it seems that it might be possible for an attacker located in the same “trusted” Local Area Network as the victim, after getting the victim to scan a malicious QR code, to have the victim’s computer initiate a same-LAN SMB connection to the attacker’s computer, and to capture an authentication token. That authentication token could later be used to initiate an offline brute-force attack against the user’s Windows account password.

Patches

We have removed the file URI support in commit b247aa5ffef0f9ef000772fcf9cd9c7141abded8. Electrum version 4.2.2 contains the fix.

Credits

We thank the Unciphered team, and specifically Frank Davidson <fd@unciphered.com> for responsibly disclosing this issue to us.

Affected versions

Electrum 2.1<=x<4.2.2

Known as