Electrum 4.2.2 Released

[DireWolfM14]

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.

# 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)

As you can see from the release notes above (emphasis mine,) the pairing issue with KeepKey has been fixed "using a workaround."  How do I know the issue is with the hardware wallet, and not Electrum?  The same pairing problem is endemic with the KeepKey and any desktop client I've tried.  The same problem with pairing is present with KeepKey's own bootloader and firmware update client.  The issue started after a firmware update roughly 2 years ago (IIRC,) and until now KeepKey has been unable to resolve their issue.  In order to pair a KeepKey with desktop clients one would have to run the application with administrator privileges.

I just tried the new version with one of my KeepKey HW wallets, and it pairs up smooth as silk.  Kudos to the Electrum team for stepping up and taking care of their supporters.

[NeuroticFish]

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

^^ I find these already important enough for a minor release; and the improvements to LN also matter.
I think that's not only about KeepKey

[DireWolfM14]

~

Oh, absolutely!  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.  It wasn't something they had to do, so I'm feeling quite a lot of love right now.

[nc50lc]

# Release 4.2.2 - (May 27, 2022)
 * fix "Automated BIP39 recovery" not scanning change paths (#7804)

So they immediately fixed this after o-e-l-e-o submitted the issue in GitHub.
Gotta take note of that version in case some newbie experience the same issue like this one: https://bitcointalk.org/index.php?topic=5391541.msg60068150#msg60068150

[o_e_l_e_o]

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.

The same applies to the issue I raised that nc50lc linked to above. As we know, Electrum does not even generate BIP39 seed phrases, but still supports them. And within an hour of me opening the issue about the user who was having trouble recovering from his BRD wallet, SomberNight had already made the necessary changes to the code to resolve the issue and make recovering these types of wallets easier. So again, going out of his way to support a problematic wallet.

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

[dkbit98]

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.

Thanks for posting this update, and I see there are few Lightning Network improvements as well.
Keepkey is probably not keeping up with Trezor code after they branched out, and 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, but this is good news  for people that already won them, like in your case.
I don't know if this issue was only with Electrum or KeepKey worked with other software wallets like Specter Desktop or Sparrow Wallet.

[DireWolfM14]

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

I think they broke something long before that.  When I first bought the wallet there was a desktop app provided by KeepKey.  I used it with Electrum from the get-go because the native app only supported legacy addresses.  At some point KeepKey merged with ShapeShift and they ported the desktop app into a google chrome extension, but the standalone app was still available.  Shortly after that a firmware update broke the ability to pair the device with the desktop app, unless it was started with admin privileges.  The same applied to pairing with Electrum.  To fix that issue, they stopped supporting the desktop app. 

It seems obvious that KeepKey doesn't really care about this.  They would just as soon have all KeepKey owners limited to using ShapeShift to manage their accounts.

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

That makes two of us. 

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

I don't use either of those wallets so I haven't tried.  When Core 22 was released with hardware support I was able to pair my Nano S, but the KeepKey was problematic.  I assume it was the same issue that prevented it from pairing with Electrum.  I don't expect Specter would behave any differently, since it's mainly just an alternative gui for Core.  Sparrow is also is just a gui wrapper around Electrum, so again I doubt it would behave differently with the KeepKey.

[NeuroticFish]

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

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.

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).

[DireWolfM14]

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

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.

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).

Good catch.  Interesting that the release notes don't mention anything about that issue.  It looks like this attack vector could be used to brute force the Windows password of a user who opens a pay request using a QR code.  It's specific to Windows machines only, and only if you use QR codes to import pay requests.  It appears that versions between 2.1 and 4.2.2 have this vulnerability.  Here're the details I found on Github:

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 <fd@unciphered.com> for responsibly disclosing this issue to us.

[hugeblack]

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.

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.

[DireWolfM14]

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.

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 think the attack vector was somewhat trivial, not something that is necessarily practical for a hacker to use as a way to steal your coins.  Regardless, a responsible development team that learns of a potential attack vector of any kind resulting from using their program knows that isn't cool.  So when the Electrum dev team learned about this potential attack vector they addressed it.  Just more evidence of what a great group of folks we've got working on Electrum.

[NotATether]

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

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

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.

So we'll have plenty of time to address that problem when it eventually crops up. At least we don't have to worry about it at this time.

[o_e_l_e_o]

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.

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'. Given that the problem described here was a legacy wallet sending its change to segwit change addresses, we could see the same problem in the near future with a legacy or segwit wallet sending its change to taproot change addresses (which Electrum does not support or therefore scan for at all yet).

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.

[DaveF]

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.

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.

-Dave

[DireWolfM14]

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'.

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 had learned about this some time ago when I wanted to restore an old seed in Electrum, then I had re-learn it this past weekend when I helped a buddy get set up with Bisq.

Way too much shit to remember, and even though I do like Bip39 seeds for various reasons, things like that make it clear why Electrums seed generation method is superior.

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.

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.).

A better graphical interface pertaining to derivation paths and multiple accounts would solve a lot of problems for newbies.  They did a good job with the interface differentiating between "Legacy" and "Segwit" wallets, but not accounts within.  I don't see hardware wallet manufacturers moving away from derivation paths for multiple accounts anytime soon, so I would be nice to see Electrum find a decent way to allow users to see those options during setup of a new wallet.

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.

Lol, I know, right?  The only "coding" experience I've had in the last 25 years is writing post processors for CAM programs to pump out ISO-6983 g-code in a format that the machinists are used to, but it's so common that you fix one thing only to have another break.  I can only imagine what a nightmare that can be for a program as complex as a bitcoin wallet.

[nc50lc]

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.

The derivation path is just telling the client to "derive the child key of this path", thus it will derive a private and public key pair down to the 'address index',
then the client just derive the SegWit address from that particular public key, regardless of the purpose field.

[o_e_l_e_o]

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

https://xkcd.com/927/

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

Yeah, another good example of a non-standard derivation path which Electrum's "Detect existing accounts" button would not pick up. 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.

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

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.)

[DireWolfM14]

https://xkcd.com/927/

Lol, too true.

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.

Bisq is an absolutely awesome service.  Obviously not as powerful of a "wallet" as Electrum, but that's not the point of the system.  It's by FAR my favorite p2p exchange, and one of the reasons is the great documentation and service community.

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 is an interesting subject;  I've used the same seed phrase to generate multiple types of wallets, Electrum makes it pretty easy with a Bip39 phrase.  Most hardware wallets allow users to create legacy, nested, and native wallets/accounts, and so far all the ones I've used stick the standard of 44=legacy, 49=nested segwit, 84=native segwit. 

Up until I attempted to import a Bisq seed into Electrum I was under the impression that the address types were hard-coded to the derivation "purpose."  But no, it's not.  I've conducted the below experiment before to make sure I wasn't insane.  As it turns out I'm only crazy; the test below uses a bip39 seed, and with the settings as shown it creates a native segwit wallet:

[o_e_l_e_o]

Up until I attempted to import a Bisq seed into Electrum I was under the impression that the address types were hard-coded to the derivation "purpose."

This is kind of true for Electrum seed phrases, in that each Electrum seed phrase is either "legacy" or "segwit" and uses a fixed derivation path (m for legacy, m/0' for segwit), and when recovered to Electrum the same seed phrase will only ever generate a single specific wallet. You could use an Electrum seed phrase at a different derivation path or with a different script type, but it would need a lot of tinkering to make it happen and would be complete non-standard (and not recommended).

BIP39 seed phrases on the other hand will let you use any derivation path combined with any script type that you like, as you've just discovered.

[DireWolfM14]

This is kind of true for Electrum seed phrases, in that each Electrum seed phrase is either "legacy" or "segwit" and uses a fixed derivation path (m for legacy, m/0' for segwit), and when recovered to Electrum the same seed phrase will only ever generate a single specific wallet.

It's pretty easy to use Electrum with a seed that was generated by Electrum for this reason.

You could use an Electrum seed phrase at a different derivation path or with a different script type, but it would need a lot of tinkering to make it happen and would be complete non-standard (and not recommended).

Yeah, I've had to do this in a pinch.  I was at work and needed a nested segwit address for some reason, so I made a temporary wallet with my Electrum seed phrase.  All I had to do was lie to the software and pretend the seed was a bip39, and it let me do what I wanted.  Pretty easy tweak, but for obvious reasons I don't recommend it.