Password protect the JSONRPC interface

[ghost]

The JSONRPC interface is currently completely unprotected, I believe it should be a priority to add at least some form of password protection.

Scans for the JSONRPC interface of Ethereum wallets have already started: https://www.bleepingcomputer.com/news/security/theres-some-intense-web-scans-going-on-for-bitcoin-and-ethereum-wallets/

[anacondabitch]

my question: is it safe to type password (passphrase) with bare keyboard or use windows virtual keyboard

[dariusc93]

@anacondabitch if you believe there is a keylogger on your computer, using the virtual keyboard should help.

[anacondabitch]

@allanhorwitz no its an attack

[zatricky]

Is there a CVE id for this? Distros typically don't know packages need to be updated without one.

[nwsm]

Even with the fix in place, any wallets that were already compromised (but possibly not taken advantage of yet) are still compromised and should be replaced, correct?

[ecdsa]

@zatricky I just submitted one

[mautematico]

@nwsm correct.

If you have any reason to suspect your wallet has been compromised, you shall create a new one (with different seeds), put a passphrase on it and transfer your coins from old compromised wallet to new one.

[loshchil]

there must some sort of internal communication system so that every user will get announcements about critical vulnerabilities like the one described in this thread otherwise, it is very irresponsible to believe that the users under risk (the ones who didn't encrypt their wallets) are familiar with github && check reddit/twitter news during NY vacations.

[mautematico]

@loshchil it is irresponsible itself if a user decides not to encrypt their wallets. Also, users don't need to be familiar with github or anything else. They just need to keep their software up-to-date.

However, I agree that we need a proper way to let users know there are critical bugs. Are you able to come up with a solution and propose it in a PR?

[loshchil]

@mautematico

They just need to keep their software up-to-date.

The current situation we are in is a good example that the above-mentioned view is hard to defend if user's security is taken into account. More specifically, a few moments after the vulnerability appeared on github, a ton of responsible users who used the most recent version so far have become targets to trivial exploits (i.e., hundreds or thousands of hackers are qualified to implement them) which could allow to hack wallets with or without brute-forcing their passwords.

I appreciate your proposal to come with a solution and a PR. However, I will limit my contribution to this reply here.

My proposal would be to i) Make Electrum regularly check whether a more recent version is available. ii) Modify Electrum main window title/caption "Electrum x.y.z" to "Electrum x.y.z TEXT", where TEXT depends on the situation we are in. For instance, it can be empty, "(is not safe to use)", "(outdated but does not have known vulnerabilities)", "(outdated and has known vulnerabilities)" iii) Update Electrum.org to have a section where known vulnerabilities are described version-wise and a set of best practices to deal with them is presented.

[ghost]

@attritionorg, invalid reference, because that bug i submitted is not by any means related to this issue, if you had properly read and understood the bug report you would understand that, but youre probably too busy sending people boxes of feces to care

[msadar]

@ecdsa

what if I never access to the previous version and deleted the wallet software? which means keeping as cold storage?

[leonklingele]

@msadar you were only susceptible to an attack while Electrum was running and your wallet unlocked. Nevertheless, as it is unknown whether the bug has been exploited, it might be worth to create a new cold wallet / Electrum wallet, encrypt it, and transfer your funds to it.

[AngelTs]

It is an excellent example why you should use only the ported version: because the ported version (even with bug(s)) in most cases is used for a very short time (set cd/usb stick, do stuff, then remove it), while installed version is very probably to works all time!

[zatricky]

@ecdsa re CVE id, is there a place where we will know it has been issued? Or will you be posting it here when it has been issued?

[ecdsa]

@zatricky you can check https://docs.google.com/spreadsheets/d/1PlDOsZ4Q36JU4Dz9zyBB2F3814dScppCRCe1muCT7JI/edit#gid=1009122160

[attritionorg]

That sheet is for assignments requested via DWF, a CNA that handles some open source software. If you request via the form on MITRE's web site, you won't be able to look it up until it is published, or the requesting party receives the assignment and posts it here.

[petterreinholdtsen]

Hi. Do you need help getting a CVE assigned, or is the process already in progress? I could ask the Debian security team for one, if it is useful.

[ecdsa]

@petterreinholdtsen I filled the form on MITRE, and my request is listed on the document linked above. Is there something else I need to do? I am not familiar with the process.

[petterreinholdtsen]

I'm not sure either, but have no better suggestion. I asked on #debian-security and it seem to be the recommended approach based on the feedback there.

[carnil]

The assigned CVE for this issue looks to be CVE-2018-1000022

[attritionorg]

@carnil have a reference for that? CVE-2018-6353 was assigned and opened:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-6353

[mithrandi]

CVE-2018-6353 is for #3678, a different issue.

[carnil]

@attritionorg: it was apparently assigned by DWF project. I got that confirmation by MITRE, since I stumpled over the CVE when I was investigating CVE-2018-6353, which mentioned "a different vulnerability than CVE-2018-1000022". I queried about this MITRE, who confirmed that DWF has assigned the CVE (but not yet published back?).

As @mithrandi stated the CVE-2018-6353 is for #3678, whereas CVE-2018-1000022 is for #3374

[mautematico]

Someone could please delete file posted by @Ruethairat?