Luckily this is fixed in the latest version (v1.11.0), so if you're a Signal user (you should be!) and you haven't upgraded already, you should upgrade immediately.
I don't see how going from one IM silo to another just because it's encrypted is going to help with anything. Especially one that's hostile towards alternative clients. I'm using XMPP with OMEMO, as I should be :P
As soon as I saw the Signal client was a web browser disguised as a desktop application, I have expected the discovery of similar issues. But as I only use Signal as an upgraded version of Plain Old Telephone for secure communication of the common people (I guess this is why the OP said "you should", not as an attack to other chats, because it serves a purpose), only talk to those people who knew my personal phone number, I didn't worry it too much. For other communications, I use PGP+E-mail, OTR/OMEMO+XMPP, IRC, Matrix, etc.
OMEMO actually implemented the double-ratchet algorithm developed as part of the Signal Protocol. Signal, in my eyes, is still the benchmark for balance between usability and security. That's fine if you prefer XMPP w/ OMEMO, and it's arguably just as secure.
...but it's unfair to call Signal another IM silo that's "hostile" towards other clients. Signal is 100% open source, along with the Signal Protocol which powers it all. It is community supported and wholly dedicated to brining cryptography to everybody. The latest implementation of OMEMO as it exists today would not be what it is without Signal.
Sure, Signal contributed back to the whole IM scene some very useful things, I'm grateful for that. That still won't make me use or recommend their network, as they actively request alternative clients to stop using their servers and are just yet another, centralized network that can just go away at any moment.
In Poland I don't see many people using Signal yet. I'm recommending Conversations to anyone who asks, which doesn't seem far away in terms of usability. On desktop it's a bit worse (I mean, I'm very comfy with my Psi, but wouldn't recommend it to a random person on the street), however Dino looks very promising and might fill that niche soon.
A relevant blogpost by Moxie about why the Signal app uses a centralized model (and thus doesn't allow other apps to connect to their servers): https://signal.org/blog/the-ecosystem-is-moving/
Still all code is open source and Signal's code does support federation. Moxie stated before that you can take the code and start a federated version of Signal if you want.
I agree with you that OMEMO + XMPP is much preferred, however the on boarding process for that is significantly more challenging compared to Signal (Download App, Start Messaging). I've managed to get a fair amount of my friends and family to go the Signal route. It's a compromise, but one that I'll live with for now.
Encrypted Open Source Messaging > Non-encrypted messaging
Too bad, I don't have a phone. I never understood why Moxie thought that only allowing phone users would be a good idea.
Also, considering how Moxie is against other clients (see the libresignal case) and at the same time considering that Signal is centralised (and Moxie refuses to federate) I would argue that you should not be using it.
It should have been done via DOM manipulation in the first place. What Signal developers did can be compared to constructing raw SQL requests where parameterized queries suffice. Thankfully, it was just fixed: https://github.com/signalapp/Signal-Desktop/commit/4e5c8965f...
I know that an unsanitized HTML input is a stupid issue to begin with, but update issued within 24 hours of discovery (and within 5 hours from disclosure)? That's really impressive.
And for encryption, absolutely should when in doubt.
The HTML tag attack on PGP works by mixing plain and cipher text, which is a thing people might genuinely want to do. But the safer clients still interfered with it by re-encrypting anything which didn't begin with a PGP signature, for the very good reason that they couldn't trust mixed messages. The clients which mildly constrained inputs prevented the entire attack vector, and it looks a very good tradeoff right now.
>EFF’s recommendations: Disable or uninstall PGP email
plugins for now. Do not decrypt encrypted PGP messages
that you receive. Instead, use non-email based
messaging platforms, like Signal, for your encrypted
messaging needs.
And ironically enough, both security issues are triggered by HTML, without HTML world would be a much better place. Seriously speaking, using plain commandline PGP or GnuPG can be a safer form of communication on desktops, but not with email clients that support HTML, and don't forget the inherent drawback of no forward secrecy.
Certainly awful timing, and especially awkward since a prepended img tag was one of the mechanisms for attacking PGP clients as well.
That said, the EFF recommendation turns out to be somewhere between 'overzealous' and 'wrong'. If you're using Protonmail or another solid GPG implementation, the attack is already handled in full by re-encrypting mixed plain/cipher messages and requiring MDC.
Just one additional note that might not be immediately clear from the advisory: Exploiting this requires the attacker to first manually place malware (a malicious JavaScript file) on your computer or on a Samba network share that your computer is already connected to.
Yeah. That fact seems pretty hidden in the reports. Due to proper CSP only local files will be executed.
If you are who I think you are, maybe you could speculate if there is actually any use for this other than loading local files (local file execution) and crashing signal?
If a .js file is redirected to from a web page, with a Content-Disposition header marking it as a download, and (as is common) the browser downloads automatically to ~/Downloads, doesn't that leave the .js file in a predictable place that can then be used by an attack on Electron?
> ... or on a Samba network share that your computer is already connected to.
Does CSP prevent this working with, for example, a malicious.js file on a remote, attacker-controlled Samba server (configured to allow "anonymous" connections)?
> Exploiting this requires the attacker to first manually place malware (a malicious JavaScript file) on your computer or on a Samba network share that your computer is already connected to.
I'm Alfredo Ortega, part of the team that wrote the original exploit. This is (unfortunately) not true. The exploit on the video was loaded from a Windows share that the victim's computer was not already connected. This is possible using "Anonymous shares" in Windows 10, and older windows versions.
To be clear, you need absolutely no additional software on the victims computers, besides having a vulnerable signal-desktop and be running on windows.
I think that future is already here. I'm seeing a lot of development of desktop Matrix clients, which to some extent has to be driven by desktop Riot being an Electron app.
Electron wouldn't be needed if browsers provided controlled access to a small selection of local resources like filesystems.
Why don't developers who think they need Electron instead just run as standalone browser windows with controlled resource access as suggested? Answer: because browsers haven't done the work required to provide the stuff that people think they need from electron.
The core idea that is flawed with Electron is that there really shouldn't be any context in which an application needs unrestricted access to the underlying OS - what application needs that? Electrons combines such unrestricted access with the ability to download and run code from the web which is a recipe for disaster. The effort being put into Electron should instead go instead putting controlled access to local resources into browsers.
40 comments
[ 3.3 ms ] story [ 87.4 ms ] threadLuckily this is fixed in the latest version (v1.11.0), so if you're a Signal user (you should be!) and you haven't upgraded already, you should upgrade immediately.
I don't see how going from one IM silo to another just because it's encrypted is going to help with anything. Especially one that's hostile towards alternative clients. I'm using XMPP with OMEMO, as I should be :P
...but it's unfair to call Signal another IM silo that's "hostile" towards other clients. Signal is 100% open source, along with the Signal Protocol which powers it all. It is community supported and wholly dedicated to brining cryptography to everybody. The latest implementation of OMEMO as it exists today would not be what it is without Signal.
In Poland I don't see many people using Signal yet. I'm recommending Conversations to anyone who asks, which doesn't seem far away in terms of usability. On desktop it's a bit worse (I mean, I'm very comfy with my Psi, but wouldn't recommend it to a random person on the street), however Dino looks very promising and might fill that niche soon.
Still all code is open source and Signal's code does support federation. Moxie stated before that you can take the code and start a federated version of Signal if you want.
> (and thus doesn't allow other apps to connect to their servers)
"thus"? You can easily use centralized model and allow the client ecosystem to thrive. You don't have to do much, just don't actively prohibit them.
And I know the blog post, it isn't very convincing.
Encrypted Open Source Messaging > Non-encrypted messaging
Too bad, I don't have a phone. I never understood why Moxie thought that only allowing phone users would be a good idea.
Also, considering how Moxie is against other clients (see the libresignal case) and at the same time considering that Signal is centralised (and Moxie refuses to federate) I would argue that you should not be using it.
https://github.com/signalapp/Signal-Desktop/commit/9d41b8616...
> Remove escaping from `linkText` > We leverage jQuery’s HTML escaping in `$.html(…)`.
ummm.... wat
Input is never the issue, output is: you don't know how the input will be used/rendered, so it should be messed with as little as possible.
The HTML tag attack on PGP works by mixing plain and cipher text, which is a thing people might genuinely want to do. But the safer clients still interfered with it by re-encrypting anything which didn't begin with a PGP signature, for the very good reason that they couldn't trust mixed messages. The clients which mildly constrained inputs prevented the entire attack vector, and it looks a very good tradeoff right now.
>Solution/Vendor Information/Workaround
>For safer communications on desktop systems, please consider the use of a safer end-point client like PGP or GnuPG instead.
---
Meanwhile, regarding yesterday's PGP flaw:
https://www.eff.org/deeplinks/2018/05/not-so-pretty-what-you...
>EFF’s recommendations: Disable or uninstall PGP email plugins for now. Do not decrypt encrypted PGP messages that you receive. Instead, use non-email based messaging platforms, like Signal, for your encrypted messaging needs.
That said, the EFF recommendation turns out to be somewhere between 'overzealous' and 'wrong'. If you're using Protonmail or another solid GPG implementation, the attack is already handled in full by re-encrypting mixed plain/cipher messages and requiring MDC.
https://protonmail.com/blog/pgp-vulnerability-efail/
https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06033...
It seems like rather poor timing to make such a derogatory comment.
If you are who I think you are, maybe you could speculate if there is actually any use for this other than loading local files (local file execution) and crashing signal?
Does CSP prevent this working with, for example, a malicious.js file on a remote, attacker-controlled Samba server (configured to allow "anonymous" connections)?
So, 'self' is ALL file:// URIs.
file://<Evil-IP>/evil.js
I'm Alfredo Ortega, part of the team that wrote the original exploit. This is (unfortunately) not true. The exploit on the video was loaded from a Windows share that the victim's computer was not already connected. This is possible using "Anonymous shares" in Windows 10, and older windows versions.
To be clear, you need absolutely no additional software on the victims computers, besides having a vulnerable signal-desktop and be running on windows.
(submitted yesterday at https://news.ycombinator.com/item?id=17070032)
It used to be that XSS is was only an issue on the web, but thanks to Electron it is now everywhere, including desktop and mobile apps.
Why don't developers who think they need Electron instead just run as standalone browser windows with controlled resource access as suggested? Answer: because browsers haven't done the work required to provide the stuff that people think they need from electron.
The core idea that is flawed with Electron is that there really shouldn't be any context in which an application needs unrestricted access to the underlying OS - what application needs that? Electrons combines such unrestricted access with the ability to download and run code from the web which is a recipe for disaster. The effort being put into Electron should instead go instead putting controlled access to local resources into browsers.