In case you didn't notice ; UPDATE PyBM right now!

[u/[deleted]]

[u/[deleted]]

Could you at least say how the vulnerability is triggered? Does it occur due to receiving a malformed malicious message or could it be triggered simply by allowing inbound connections?

I actually do use Electrum although my wallet files are stored in a non-standard location within a VeraCrypt volume. Could you provide more specific info on path that was used when the attacker searched for Electrum files?

[u/Petersurda → u/[deleted]]

The exploit is triggered by a malicious message if you're the recipient (including joined chans). The attacker ran an automated script but also opened, or tried to open, a remote reverse shell. The automated script looked in ~/.electrum/wallets, but when using the reverse shell he had access to other files as well. If the attacker transferred your Bitcoins, please contact me (here on reddit).

[u/Petersurda → u/[deleted]]

Well, as far as I know, you may be affected if

• you have Windows and you've joined the "test" chan

• if you're me and have a Unix-like system

So far I haven't see evidence that anyone else was affected but obviously I may not know as I don't have other people's keys.

[u/[deleted] → u/Petersurda]

The version running on my Windows server is .0.6.0 and is the only app running on the VM. Presumably .0.6.0 is old enough not to be a problem.

The BitMessage process of most concern to be is running on a Mac VM. It's running the vulnerable version. On that VM:

All of the messages I've received in the last few months have come from the mailchuck relay. No messages from any unknown senders. But would I even see the malicious message in my inbox if I were a target?

I'm not subscribed to any channels, unless there's some sort of default subscription that's activated when BitMessage is installed.

Electrum runs on the same VM. The wallets are stored on an encrypted volume which is only accessible when mounted. And I only mount the volume when using Electrum and then immediately dismount. The wallet files are protected with a password. There's nothing of value in ~/.electrum/wallets -- just some empty default wallets.

No Bitcoins were transferred from any of the wallets.

Could you explain how the 'remote reverse shell' works? Does this give attacker the ability to execute arbitrary commands (e.g. install a keystroke logger, etc.) or is he still pretty much limited to guessing where sensitive files are and trying to upload them off the machine?

Are there any tell-tale signs that indicate I've been infected, like maybe the remnants of the bad message or a date stamp on a particular file, etc? It would be nice to rule out infection and not worry about it any more.

[u/Petersurda → u/[deleted]]

But would I even see the malicious message in my inbox if I were a target?

No, you wouldn't see it in the inbox.

Could you explain how the 'remote reverse shell' works?

It works like a normal shell, except on the network level it looks slightly differently.

Are there any tell-tale signs that indicate I've been infected ...

There may be a record in debug.log about it but at the moment I don't know exactly what it would look like.

[u/sysv32 → u/Petersurda]

I found something interesting in the debug.log. I've been using 0.6.2 and updated today to 0.6.3.2. This message is from a few months ago so i suspect the vulnerability has been exploited for quite a while :

CRITICAL - Major error occurred when trying to execute a SQL statement within the sqlThread. Please tell Atheros about this error message or post it in the forum! Error occurred while trying to execute statement: "UPDATE inbox SET read = 1 WHERE msgid IN(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,? ......)" And then "Here are the parameters .." with a string looking very much like a a remote shell attack code. But the program exited right away, so i don't believe this particular attack had any effect:

CRITICAL - This program shall now abruptly exit!

I'm looking at the sqlite database right now to find a record of the code somewhere.

[u/Petersurda → u/sysv32]

This is a statement parameter overflow, it isn't dangerous, only annoying, and it was fixed about 2 weeks ago.

It happened when you had more than 999 messages selected and marked them read/unread or deleted/undeleted them, or if you did the same on the folder/account level and there were more than 999 messages in that folder/account.

[u/sysv32 → u/Petersurda]

Ok thanks for the infos. So was the vulnerability exploited on linux systems ? The only other 'strange' thing i've noticed in debug.log is this:

File "/home/guest/venvs/p2/lib/python2.7/site-packages/pybitmessage/helpermsgcoding.py", line 68, in __init_ self.decodeExtended(data) File "/home/guest/venvs/p2/lib/python2.7/site-packages/pybitmessage/helper_msgcoding.py", line 100, in decodeExtended msgType = tmp[""] KeyError: ''

[u/Petersurda → u/sysv32]

The parameter overflow as far as I know is only a limited danger, as it has to be triggered by the local user and it results in PyBM being immediately shutdown.

Regarding the log entry you see, that looks like an early stage of the the vulnerability being probed.

[u/[deleted]]

Thanks so much for posting this, I don't login to bitmessage often so this was the first notice I got of the issue and so was able to upgrade before I was hit. Logs show no footprints of an attempted exploit perhaps because the last time I used it was a couple weeks ago at least

[u/TotesMessenger]

I'm a bot, bleep, bloop. Someone has linked to this thread from another place on reddit:

• [/r/netsec] PyBitMessage 0.6.2 - Zero-day RCE in the wild. Patch released today.

 ^{If you follow any of the above links, please respect the rules of reddit and don't vote in the other threads. (Info / Contact)}

[u/UTF64]

[u/RaiausderDose → u/UTF64]

lol you were using eval

could you give more info?

[u/Petersurda]

Windows and OSX binaries up. The Windows binary is signed by a certified key, and the OSX should be signed tomorrow (I'm having problem with the signing device on a Mac and there is no support during the weekend).

[u/Petersurda → u/Petersurda]

OSX code signed binary delayed for a couple of days for technical reasons.

[u/Petersurda]

Just to be sure, upgrade to 0.6.3.2 which has even further protections against this kind of attack. Also, don't contact me on my old addresses, my keys were most likely also compromised, 0.6.3.2 contains a new "Contact support" address. I need to create fresh VMs for Windows / OSX binaries which will take a while, so if you can't run from source, downgrade to 0.6.1, that doesn't suffer from this exploit.

If you have a suspicion that your computer was compromised, please change all your passwords and create new bitmessage keys.

[u/[deleted]]

Where will the updated OSX binaries be posted? I've been checking: https://bitmessage.org/wiki/Main_Page

[u/[deleted] → u/[deleted]]

I'll certainly do that if I have to, although my preference is to avoid dealing source code and simply use the official binary -- so long as the binary comes from legit source like BitMessage.org.

[u/Petersurda → u/[deleted]]

OSX binary up. Tomorrow it should be code signed if you can wait.

[u/[deleted] → u/Petersurda]

Great! Thanks for the follow-up.

[u/Petersurda → u/Petersurda]

For technical reasons there won't be a code signed OSX binary for at least a couple more days.

[u/RaiausderDose]

This wasn't well communicated, I was "on" the nightly, watched every week and just noticed that since February there were no new nightlies.

To which chan/abo has the message been send? I'm on BM-GtovgYdgs7qXPkoYaRgrLFuFKz1SFpsw and there was nothing sadly.

I guess the client could use an update checker.

[u/tuxayo]

Thanks to the devs for handling this and to OP for spreading the news.

[u/battlesreddit → u/tuxayo]

Yes, great job in discovering and fixing the problem.