Signal-desktop HTML tag injection advisory | Hacker News Reader

Signal-desktop HTML tag injection advisory

ivan.barreraoro.com.ar

77 pointsthrowwwafgk37 comments

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

Please do not quote with codeblocks as it is unreadble on mobile.

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

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.

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

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?

that could probably.be answered by jlund. Electron downloading things by default seems like a pretty bad thing to do.

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

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

file://<Evil-IP>/evil.js

> 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 was incorrect about this, and I apologize.

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

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.

Of course you can. That won't be Signal though, just an another network using its code, and there's already XMPP, so there's no need for that.

> (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.

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

SIGFAIL? Where's the vanity domain and whitepaper?

Or SIGINT, would be a good NSA joke. https://en.wikipedia.org/wiki/SIGINT

If you're interested in the how, who, what and where, there's a more chatty account of how this vulnerability was discovered, reported, fixed and disclosed here: https://ivan.barreraoro.com.ar/signal-desktop-html-tag-injec...

(submitted yesterday at https://news.ycombinator.com/item?id=17070032)

Good old unsanitized HTML. Brings memories of the first bulletin boards.

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

Frankly, I'm not to eager to trust people writing commit messages like this and then OK that during peer review:

https://github.com/signalapp/Signal-Desktop/commit/9d41b8616...

> Remove escaping from `linkText` > We leverage jQuery’s HTML escaping in `$.html(…)`.

ummm.... wat

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.

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.

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

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.

> For safer communications on desktop systems, please consider the use of a safer end-point client like PGP or GnuPG instead.

It seems like rather poor timing to make such a derogatory comment.

Dat timeline.

Reply on news.ycombinator.com