Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Signal-desktop HTML tag injection advisory

ivan.barreraoro.com.ar

Post reply on HN
Print view View original

31–40 of 41 posts

Re: Signal-desktop HTML tag injection advisory

#31

Post by seba_dos1 »

opmac wrote: post #29
seba_dos1 wrote: post #8

Earlier quoted context omitted.

> (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 power…

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.

Re: Signal-desktop HTML tag injection advisory

#32

Post by andrewstuart »

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.

Re: Signal-desktop HTML tag injection advisory

#33

Post by bjoli »

nitrogen wrote: post #28
bjoli wrote: post #19

Earlier quoted context omitted.

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.

Re: Signal-desktop HTML tag injection advisory

#34

Post by sicco »

seba_dos1 wrote: post #31
opmac wrote: post #29

Earlier quoted context omitted.

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 power…

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, whic…

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.

Re: Signal-desktop HTML tag injection advisory

#36

Post by NoGravitas »

zeveb wrote: post #24

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.

Re: Signal-desktop HTML tag injection advisory

#37

Post by seba_dos1 »

sicco wrote: post #34
seba_dos1 wrote: post #31

Earlier quoted context omitted.

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, whic…

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.

Re: Signal-desktop HTML tag injection advisory

#38

Post by ycmbntrthrwaway »

FranOntanaya wrote: post #4

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

Re: Signal-desktop HTML tag injection advisory

#39

Post by rndgermandude »

ycmbntrthrwaway wrote: post #38
FranOntanaya wrote: post #4

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

Re: Signal-desktop HTML tag injection advisory

#40

Post by aortega »

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.

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

Post reply on HN