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

Another flaw in Signal desktop app leaks chats in plaintext

thehackernews.com

Post reply on HN
Print view View original

121–130 of 232 posts

Re: Another flaw in Signal desktop app leaks chats in plaintext

#121

Post by grrowl »

rndgermandude wrote: post #57
pfg wrote: post #9

Earlier quoted context omitted.

As much as I'm not a fan of JavaScript, the problem is not so much the language but rather the choice of Electron and all that comes with it. Heck, even a web version or Chrome app would've successfully mitigated these attacks. Electron means you're one XSS away from remote code execution, and even worse, it makes it way harder to mitigate XSS through CSP (which Signal did utilize, but script-src 'self' can easily be…

While I agree that Electon offers a massive amount of footguns, neither Javascript nor Electon was the issue in this case. The issue was using innerHTML (or rather $.html()) with strings concatenated together from user input. Something you should never do. Could as well just call eval() directly on it, or pass the input to gcc, compile it and run the resulting binary. The Signal devs thought $.html() does some kind o…

> The Signal devs thought $.html() does some kind of escaping: https://github.com/signalapp/Signal-Desktop/commit/9d41b8616.... (this commit made something that was easy to exploit into something that was even easier to exploit).

This is an absolutely egregious rookie error. I wouldn't touch the Signal desktop app with a 10 foot pole after seeing that commit.

Re: Another flaw in Signal desktop app leaks chats in plaintext

#122

Post by lnrdgmz »

symlinkk wrote: post #7
tormeh wrote: post #5

Maybe secure chat clients shouldn't be written in JavaScript or other languages that have excessive dynamicness? Signal seems to be written mostly in languages that are bad for security (significantly worse than the best alternatives). Maybe I'm just a language nerd without any clue about the trade-offs, but I trust the Wire software more. Note that this just applies to mobile clients and server - Wire, like Signal,…

None of this is caused because of them using a dynamic language. It's caused because the developers used a function literally called "dangerouslySetInnerHTML" that doesn't escape HTML. That's it. It's just lazy programming.

Naive question: Are there functions analogous to `dangerouslySetInnerHTML` in non-JS GUI libraries (e.g. Qt) that will allow a similar attack?

Re: Another flaw in Signal desktop app leaks chats in plaintext

#123

Post by mercurial »

0x0 wrote: post #49
connorelsea wrote: post #8

Earlier quoted context omitted.

there is plenty of secure software written in javascript. poor engineering can occur in any language

If a presentation layer API (=HTML) provides developers with the convenience of composing UI elements by concatenating markup with remotely sourced input, and at the same time allows inline scripts to be eval'ed when merely present in particular markup attributes, and additionally sometimes hooks up un-sandboxed native APIs with full access to $HOME, it has really laid down the groundwork for a client-side can of wor…

A database provides developers with the convenience of composing queries by concatenating strings. You still need to be really incompetent to do so in 2018.

Re: Another flaw in Signal desktop app leaks chats in plaintext

#124

Post by AgentME »

pfg wrote: post #9
tormeh wrote: post #5

Maybe secure chat clients shouldn't be written in JavaScript or other languages that have excessive dynamicness? Signal seems to be written mostly in languages that are bad for security (significantly worse than the best alternatives). Maybe I'm just a language nerd without any clue about the trade-offs, but I trust the Wire software more. Note that this just applies to mobile clients and server - Wire, like Signal,…

As much as I'm not a fan of JavaScript, the problem is not so much the language but rather the choice of Electron and all that comes with it. Heck, even a web version or Chrome app would've successfully mitigated these attacks. Electron means you're one XSS away from remote code execution, and even worse, it makes it way harder to mitigate XSS through CSP (which Signal did utilize, but script-src 'self' can easily be…

>Electron means you're one XSS away from remote code execution, and even worse, it makes it way harder to mitigate XSS through CSP (which Signal did utilize, but script-src 'self' can easily be bypassed in Electron).

Can you explain that last part? I can't think of how an XSS attack could get around that, and Electron's documentation specifically recommends it: https://github.com/electron/electron/blob/master/docs/tutori...

Re: Another flaw in Signal desktop app leaks chats in plaintext

#125

Post by verroq »

Ceezy wrote: post #120
tlrobinson wrote: post #105

Why is this flagged?

Because the discution is already a flame war. I feel like everybody has a solution. Try not to get burn because JS is bad! a sorry electron is terrible! No innerhtml is a sin!

I thought we already accepted that JS is bad. It is objectively a bad language, with the weak typing, quirky edge cases and a hundred bad libraries, and some backdoored ones available on npm as well.

We've also accepted that Electron is bad, we don't need native applications that bundle Chrome so they can run JavaScript. It's a bloated memory haemorrhaging mess pretending to be a cross platform framework.

And if that wasn't bad enough, we have JavaScript developers who know nothing about security, writing a supposedly "secure" desktop app where a XSS is now a RCE.

We've come such a long way that browsers can now almost securely execute JavaScript and you're telling me that a 2018 "secure" chat messaging desktop application has a RCE from a XSS in the messaging feature. It sends and receives text to other people for god's sake. Myspace wasn't even this bad and it didn’t pretend it was secure.

It is absolute lunacy. I won't be surprised that the Signal desktop brand is completely ruined by all this fallout because these are just rookie mistakes compounded on rookie mistakes.

Re: Another flaw in Signal desktop app leaks chats in plaintext

#126

Post by mtgx »

symlinkk wrote: post #7
tormeh wrote: post #5

Maybe secure chat clients shouldn't be written in JavaScript or other languages that have excessive dynamicness? Signal seems to be written mostly in languages that are bad for security (significantly worse than the best alternatives). Maybe I'm just a language nerd without any clue about the trade-offs, but I trust the Wire software more. Note that this just applies to mobile clients and server - Wire, like Signal,…

None of this is caused because of them using a dynamic language. It's caused because the developers used a function literally called "dangerouslySetInnerHTML" that doesn't escape HTML. That's it. It's just lazy programming.

I may be wrong, but I think the Signal desktop app was written by like interns or new developers working for Signal.

The Android app was written by Moxie, and I think it's the one about which Matthew Green said:

After reading the code, I literally discovered a line of drool running down my face. It’s really nice.

https://signal.org/

Re: Another flaw in Signal desktop app leaks chats in plaintext

#128

Post by 0xCMP »

JasonFruit wrote: post #26
0xCMP wrote: post #20

Earlier quoted context omitted.

Ah, so don't use the now secured opensource client using Signal's protocol. We should use PGP with all the weak yet-to-be-patched clients. Cause it's not PGP which got hacked it was the client. Very different from how the Signal client got hacked not their protocol. /s

No, I'm saying use just PGP - manually - and don't use any client interface to it. Control the encryption yourself. Your sarcasm is misplaced.

If I accept that using PGP manually is acceptable for getting wide-spread encryption then you're right, but the fact is that tech people rarely use it because it's so cumbersome that the chance of normal users using it successfully, let alone using the terminal these days, is so slim that it's basically absurd to think that is the way we're gonna get wide spread encryption.

I don't want to only talk to my tech friends. My best friend runs a small business doing nothing to do with tech and when I talk to him I want to be sure no one else can read/listen to what we're saying because it's private. There is no version where my friend learns to properly use PGP consistently so we can talk that way. The only reasonable way is WhatsApp or Signal.

Re: Another flaw in Signal desktop app leaks chats in plaintext

#129

Post by fjsolwmv »

debacle wrote: post #91
twr wrote: post #84

Earlier quoted context omitted.

I don't know if this is correct, but, I once got the impression that Signal Desktop was under the sole purview of a new hire at OWS. In other words, Moxie doesn't review the commits. I hope I'm wrong, but even if I'm not, I suppose it makes no difference, as he's arguably responsible either way.

Isn't this supposed to be an app for secure communication? Theo would have a conniption.

Has Theo de Raadt ever endorsed the security of anything except the default install of OpenBSD?

Re: Another flaw in Signal desktop app leaks chats in plaintext

#130

Post by fjsolwmv »

jrochkind1 wrote: post #90
bigiain wrote: post #87

Earlier quoted context omitted.

Maybe, and I know this sounds crazy, secure chat clients shouldn't execute user/potential-attacker supplied code at all???

Of course they shouldn't, that is the bug, I think? The authors thought they were displaying user-supplied HTML, not executing user-supplied code. You can say secure chat clients should not display HTML messages, but that's a pretty different thing.

Yes the only problem is that the text markup language happens to include by default a Turing complete network-enabled live-interpreted programming language because 25 years ago someone wanted to write a funny message in the Netscape status bar.
Post reply on HN