Signal-desktop HTML tag injection advisory • Hacker News Board

Re: Signal-desktop HTML tag injection advisory

#21

Post by Bartweiss » Tue, May 15, 2018, 3:10 PM UTC

AdmiralAsshat wrote: post #10

Is this a joke? >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.…

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.

https://protonmail.com/blog/pgp-vulnerability-efail/

https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06033...

Re: Signal-desktop HTML tag injection advisory

#22

Post by jlgaddis » Tue, May 15, 2018, 3:12 PM UTC

jlund wrote: post #16

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.

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

Re: Signal-desktop HTML tag injection advisory

#23

Post by Bartweiss » Tue, May 15, 2018, 3:14 PM UTC

eximius wrote: post #20

masklinn wrote: post #7

Earlier quoted context omitted.

> I know that an unsanitized HTML input is a stupid issue to begin with 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.

Depends entirely on your application. Often you know, or are willing to constrain, the uses of an input.

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.

Re: Signal-desktop HTML tag injection advisory

#24

Post by zeveb » Tue, May 15, 2018, 3:18 PM UTC

In the future, I believe that we're going to consider using Electron to create pseudo-native applications a code smell.

Re: Signal-desktop HTML tag injection advisory

#25

Post by Rjevski » Tue, May 15, 2018, 3:38 PM UTC

Just another day in Electron land.

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.

Re: Signal-desktop HTML tag injection advisory

#26

Post by aegarbutt » Tue, May 15, 2018, 3:39 PM UTC

jlgaddis wrote: post #22

jlund wrote: post #16

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.

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

The CSP policy was 'self'. The problem is that all file:// URIs share an origin in Electron.

So, 'self' is ALL file:// URIs.

Re: Signal-desktop HTML tag injection advisory

#27

Post by aegarbutt » Tue, May 15, 2018, 3:41 PM UTC

jlund wrote: post #16

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.

Or I just expose my malicious share to the Internet. No mounting step necessary.

file:///evil.js

Re: Signal-desktop HTML tag injection advisory

#28

Post by nitrogen » Tue, May 15, 2018, 3:45 PM UTC

bjoli wrote: post #19

jlund wrote: post #16

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?

Re: Signal-desktop HTML tag injection advisory

#29

Post by opmac » Tue, May 15, 2018, 3:53 PM UTC

seba_dos1 wrote: post #8

opmac wrote: post #2

Ah, Electron /sigh. 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.

> (you should be!) 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

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.

Re: Signal-desktop HTML tag injection advisory

#30

Post by BostonEnginerd » Tue, May 15, 2018, 3:55 PM UTC

seba_dos1 wrote: post #8

opmac wrote: post #2

Ah, Electron /sigh. 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.

> (you should be!) 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

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