Eric from https://www.Unciphered.com here:
If you want to see the attack in action it starts at 17:28 - https://www.youtube.com/watch?v=yMz_Gfxkkks in our talk: SEC-T 0x0E: Eric Michaud & Tom Smith - Crypto Vuln Cornucopia - From the archives of Team Kairos.
The vulnerability we found existed in from 2.1 and every version to now 4.2.1 and forks of Electrum Wallet. We disclose the most utilized wallets by user base beyond Electrum Wallet in the talk that patched in a coordinated disclosure. The team EW was great to work with.
The reality of the vulnerability is that we wrote the Windows exploit in about a week once we determined the flaw which was a Python Open statement. People who have specialization writing exploits for say...iOS could take the vulnerability potentially and write a exploit for iPhone. We just wanted to prove we could get shell and/or steal a wallet which we did.
After that we reached out as fast as we could to get this patched. We wouldn't be surprised if someone wanted to write an exploit for TAILs/iOS/Android/Mac/etc etc each in the future for the versions from 4.2.1 and backwards.
Happy to chat more about this and other vulnerabilities we're discovering during work.
-E.
Topic: Electrum 4.2.2 Released (Read 544 times)
Thanks so much, that is brilliant! 
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.
Ahh sure, that's one way of doing it. In that case you aren't using your Electrum seed phrase as an Electrum seed phrase at all (with the Electrum specific salt), but rather as a (most likely) invalid BIP39 seed phrase (with the BIP39 specific salt). I was thinking of using an Electrum seed phrase as an Electrum seed phrase, but forcing Electrum to ignore the incorrect version number and derive at a custom derivation path, which would require tinkering in the source code rather than just selecting the BIP39 option in the restore menu.Either way, not recommended, and I'll stop before I go any further off topic.
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:
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.) 
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.
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.
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.
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
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).
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.
Based on commit message, looks like they forget to mention it when they release 4.2.2. It's added on newer commit.
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.).
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.
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.
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.
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'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).
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 <[email protected]> for responsibly disclosing this issue to us.
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.
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).
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).
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.
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.
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.
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.
# Release 4.2.2 - (May 27, 2022)
* fix "Automated BIP39 recovery" not scanning change paths (#7804)
* fix "Automated BIP39 recovery" not scanning change paths (#7804)
Gotta take note of that version in case some newbie experience the same issue like this one: https://bitcointalksearch.org/topic/m.60068150
Jump to: