Live data from Hacker News

Another flaw in Signal desktop app leaks chats in plaintext

thehackernews.com

101–110 of 232 posts

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

#101
post #55
post #23

Earlier quoted context omitted.

Surely this is sarcasm. Just in case it isn't, it's only fitting to link back to what Moxie Marlinspike wrote about PGP/GPG: https://moxie.org/blog/gpg-and-me/ (HN commentary: https://news.ycombinator.com/item?id=9104188 ). TL;DR: When will people start using gpg: they won't.

After reading that article I want to use PGP just so I never run the risk of interacting with people like Moxie.

I think this sentiment explains half of the negative reactions I’ve seen towards Moxie over the years. I guess it pays to be likeable.

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

#102
post #49

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…

It'd probably be useful to distinguish between runtime environments that Javascript is typically encountered (Browsers + Electron) as opposed to the language itself. If it were a language issue, a developer might believe that they could simply switch to a different language, say rust, and compile to WebAssembly and be safe.

However, as you point out, the issue lies in the presentation layer unexpectedly executing code (or receiving inputs from unexpected and untrusted sources). This issue wouldn't be solved by switching to a different language. The core issue here isn't Javascript per se, but the dangerous runtime environments that are browsers and browser approximations (electron) that are designed to execute code from 3rd parties.

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

#103
post #97
post #7

Earlier quoted context omitted.

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.

We called it that way in React in order to call out attention to the fact that it was actually dangerous. React also properly escapes everything else it prints. The app isn't using React but jQuery, which doesn't have those protections.

[deleted]

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

#104

Earlier quoted context omitted.

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: Uhm... that's a really rookie mistake to make. Like, one of the very basics of jQuery usage. I'm not exactly sure what to think about it after seeing this commit you linked...

The worst part is that someone assumed something then removed the code that did the escaping without even doing the most basic of tests, like even in the browser just doing a quick foo.html('alert("oh snap this is bad")')

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

#107
I don't know if this is exploitable, but they are using many different methods to escape HTML content:

https://github.com/signalapp/Signal-Desktop/blob/d1f7f5ee8c1...

Then here it's a different function:

https://github.com/signalapp/Signal-Desktop/blob/d1f7f5ee8c1...

Then sometimes they use the underscore library to do it:

https://github.com/signalapp/Signal-Desktop/blob/d1f7f5ee8c1...

Which their implementation seems to be using regular expressions as well.

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

#108
post #97
post #7

Earlier quoted context omitted.

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.

We called it that way in React in order to call out attention to the fact that it was actually dangerous. React also properly escapes everything else it prints. The app isn't using React but jQuery, which doesn't have those protections.

This doesn't seem to be true, here's the v1.10.0 code:

https://github.com/signalapp/Signal-Desktop/blob/f6eb745632c...

They do seem to be using react, and using dangerouslySetInnerHTML. Now that said, I haven't confirmed that this is the code that caused the issue, but it is in the Quotes component, which is referenced in the article.

They seem to have fixed this specific issue a few days ago (v.11.0):

https://github.com/signalapp/Signal-Desktop/blob/0d00fbfb7a2...

They do seem to be using jQuery elsewhere in the code base, but I'm not familiar enough to determine how it all fits together.

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

#109

When will people start using plain old PGP — a tool that does one thing only, and does it right? Sure, it's a little harder than using just one tool that handles contacts, communication, formatting, and encryption, while making popcorn and walking the dog, but it works, and it's secure if you use it right. Our efforts to make encryption easy are going to get someone killed.

I don't know anyone who uses PGP/GPG to communicate securely, and I'm a cryptographer!
Post reply on HN