Topic: Electrum 4.2.2 Released - page 2. (Read 577 times)

At least however Bisq have clear documentation as to which derivation paths they use (https://bisq.wiki/Backing_up_your_wallet_seed#Wallet_derivation_paths) as opposed to many other wallets which just leave their users guessing.

As nc50lc says, the derivation path specifies the derivation of the private key. What the client does with that private key then is completely free and open. Most wallets will stick to the BIP44/49/84 standard for legacy/nested/native, but many do not. Any private key can be used to derive any address type (or even multiple address types. It is entirely possible to use the same seed phrase to create both a legacy and a segwit wallet at the same derivation path, if you wanted.)

This has always been an issue with programmers working around other peoples code since forever, not just with BTC.

Don't forget Bisq's m/44'/0'/1' for segwit addresses.

I don't know how they were able to accomplish that, but that's how it goes.

Don't forget Bisq's m/44'/0'/1' for segwit addresses.  Yeah, for segwit!  I don't know how they were able to accomplish that, but that's how it goes.

I don't think so. In the 13 years since Bitcoin's launch, we already have many commonly used derivation paths and scripts. The three commonly used BIP44/49/84s, now BIP86 for taproot, Core's m/0'/0', and a bunch of other unique paths for certain wallets, such as Samourai's m/84'/0'/2147483645'.

I agree, although this problem could be solved if someone contribute to add list of non-default path on various wallet. It could be either simple textbox (only showing pair of wallet and it's non-default path) or option (default path, enter manually, path of wallet A, etc.).

And it's all good until with them trying to clean up other peoples poor programming or documentation they break something or introduce a vulnerability.
This has always been an issue with programmers working around other peoples code since forever, not just with BTC.
Same with the keepkey issue. How much time & effort did they spend cleaning up someone else's mess.

There really is no end to how different poorly coded wallets can confuse their users and hide their funds behind unknown derivation paths. While it is obviously very good of the Electrum devs to try to address this and help out their users, I can't help but feel it is highly unfair asking them to clean up the mess that other wallets have created.

Good catch.  Interesting that the release notes don't mention anything about that issue.

There really is no end to how different poorly coded wallets can confuse their users and hide their funds behind unknown derivation paths. While it is obviously very good of the Electrum devs to try to address this and help out their users, I can't help but feel it is highly unfair asking them to clean up the mess that other wallets have created.

Fortunately, that problem will be at least 30 years away, since it takes on average 3 years (using 1 datapoint and extrapolating by 10 more - so not accurate by any means, but just to get the feeling of time length) for Bitcoin developers to come up with another type of script that will take another witness version.

Bech32 specification mention valid witness version is 0 to 16, so i bet we'll see another problem.

So it's an offline brute-force attack against the user's Windows account password.
I don't know, but even after obtaining the Windows password, how will the hacker be able to steal the coins?
Or is he talking about the wallet password.

I've just found on Twitter some interesting/intriguing announcement.


From what it was written in here the importance of the update was not so much obvious. Now it is. So, especially the Windows users, please update asap (myself included).

Description
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 <[email protected]> for responsibly disclosing this issue to us.

Electrum 4.2.2 fixes a vulnerability that can be exploited on some Windows+SMB configurations. Please upgrade if you have not done so already.

I saw on their github page they had only one firmware update this year... they probably broke something in April.

I would not buy KeepKey wallet and I don't recommend it

I don't know if this issue was only with Electrum or KeepKey worked with other software wallets like Specter Desktop or Sparrow Wallet.

Electrum just released a new version, 4.2.2.  One of the "issues" they fixed wasn't actually an issue with Electrum, but rather an issue with a the crappy KeepKey hardware wallet.

I wonder if we'll see this type of problem become more common as we introduce more different address types beyond taproot.

I wasn't trying to minimize the other upgrades, only to highlight how the team proactively supports the community as a whole by going out of their way to support a problematic and not-very-popular hardware wallet.

~

* fix AppImage failing to run on certain systems (#7784)
 * bypass network proxy for localhost electrum server (#3126)

# Release 4.2.2 - (May 27, 2022)
 * Lightning:
   - watching onchain outputs: significant perf. improvements (#7781)
   - enforce relative order of some msgs during chan reestablishment,
     lack of which can lead to unwanted force-closures (#7830)
   - fix: in case of a force-close containing incoming HTLCs, we were
     redeeming all HTLCs that we know the preimage for. This might
     publish the preimage of an incomplete MPP. (1a5ef554, e74e9d8e)
 * Hardware wallets:
   - smarter pairing during sign_transaction (238619f1)
   - keepkey: fix pairing with device using a workaround (#7779)
 * fix AppImage failing to run on certain systems (#7784)
 * fix "Automated BIP39 recovery" not scanning change paths (#7804)
 * bypass network proxy for localhost electrum server (#3126)