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

131–140 of 232 posts

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

#131

Post by fjsolwmv »

saagarjha wrote: post #51
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,…

JavaScript may have many problems, but I don't really think security is one of them. In a properly isolated sandbox, such as a web browser, it's much more difficult to gain arbitrary code execution privileges than a native desktop app.

Then JavaScript is a huge problem, only made safe when wrapped in a professionally built and battle tested bubble.

OpenBSD is a famously secure unix(alike) distro. That doesn't mean that every piece of software in OpenBSD is safe to use in any other context.

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

#132

Post by derefr »

thaumasiotes wrote: post #85
rndgermandude wrote: post #57

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 issue was using innerHTML (or rather $.html()) with strings concatenated together from user input. > The Signal devs thought $.html() does some kind of escaping I mean, it does do a kind of escaping. If you assign javascript to innerHTML directly, it won't execute. jQuery specifically checks whether you're adding a script tag, and if so, it takes the extra step to execute it for you.

You mean, the innerHTML of a element. Which isn’t really a thing, because the inside of a tag is a document boundary—assigning raw Javascript to innerText or innerHTML directly would make no sense in either case. You need to wrap your Javascript in a CDATA node ;)

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

#133

Post by [deleted] »

ddtaylor wrote: post #104
seba_dos1 wrote: post #69

Earlier quoted context omitted.

>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") ')

[deleted]

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

#134

Post by pfg »

AgentME wrote: post #124
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…

>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/tu…

There's a bit of an explanation of this in the article describing the other XSS that's recently been found in Signal[1]. Basically, since the Electron app itself runs under the file:// origin, 'self' can be bypassed with varying degrees of difficulty depending on the platform. On Windows, it's trivial because you can use UNC paths to a SMB share containing a malicious JavaScript file (i.e. file://1.2.3.4/payload.js). On other platforms, you'd need to find a way to place the file on a path accessible via file:// first, for example by sending the file via Signal itself and hoping the user accepts the download.

There are ways to lock down the CSP further to mitigate this, but no one really expects script-src 'self' to be unsafe, especially when it's what their documentation recommends.

[1]: https://ivan.barreraoro.com.ar/signal-desktop-html-tag-injec...

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

#135

Post by fjsolwmv »

mtgx wrote: post #126
symlinkk wrote: 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.

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/

I hope Moxie learned that programming his people/team is as programming his software. This tarnishes Signal, regardless of how good the Android app is.

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

#136

Post by jancsika »

tptacek wrote: post #24

Honestly, and none of you are going to like hearing this, and the Signal people aren't going to appreciate me saying it: if you're serious about messaging securely, don't use Signal Desktop; don't use desktop secure messengers at all. Desktop applications are incredibly risky, far more so than iOS mobile apps are.

> Desktop applications are incredibly risky, far more so than iOS mobile apps are.

Ok, I'll play.

I get to choose 10 arbitrary apps from the Apple App store for you to install on an Iphone model of your choice.

You get to choose 10 arbitrary apps for me to install from the default Debian repos (which I believe excludes nonfree). Let's say Sid to make it interesting.

Who is going to be in worse shape after installing those apps?

Edit: typo

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

#137

Post by sakarisson »

namuol wrote: post #79

Pretty mindblowing that Signal allows things like `dangerouslySetInnerHTML` in any of their apps. A simple linter would have caught this.

With such an obviously "DON'T USE THIS" method name as dangerouslySetInnerHtml, I'd expect that we'd see something like // eslint-disable-next-line above it.

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

#138

Post by fjsolwmv »

_emacsomancer_ wrote: post #119
tptacek wrote: post #81

Earlier quoted context omitted.

I like open source software as much as most people on HN, and have worked with it for most of my career. But help me understand how a decentralized FOSS model gets ordinary lawyers, reporters, and congressional campaign staffers the level of security that iOS does? What are the mechanisms that assure safety for users? The closest I can come to seeing something like this work is a Chromebook, and Chromebooks are locke…

> What are the mechanisms that assure safety for users? What are the mechanisms that assure safety for users of iOS? I understand that it's had a good track record so far, but the proprietary closed nature doesn't inherently inspire trust. Surely a decentralised FOSS model done right could be secure for lawyers &c.

As the old saying goes, "if you could have invented a secure open source desktop chat app, you would have developed a secure open source desktop chat app."

In practice, empirict results win over theoretically optimal designs.

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

#139

Post by vjeux »

archgoon wrote: post #108
vjeux wrote: post #97

Earlier quoted context omitted.

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…

Oh sorry you are right! I was reading the comment ( https://news.ycombinator.com/item?id=17097501 ) which said that the issue was caused with $.html

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

#140

Post by tptacek »

jancsika wrote: post #136
tptacek wrote: post #24

Honestly, and none of you are going to like hearing this, and the Signal people aren't going to appreciate me saying it: if you're serious about messaging securely, don't use Signal Desktop; don't use desktop secure messengers at all. Desktop applications are incredibly risky, far more so than iOS mobile apps are.

> Desktop applications are incredibly risky, far more so than iOS mobile apps are. Ok, I'll play. I get to choose 10 arbitrary apps from the Apple App store for you to install on an Iphone model of your choice. You get to choose 10 arbitrary apps for me to install from the default Debian repos (which I believe excludes nonfree). Let's say Sid to make it interesting. Who is going to be in worse shape after installing…

You will be in worse shape than I will be. It's possible, in that insane proposition, that your Debian machine will be conceding remote code execution to the whole Internet, while my phone will just have some crappy apps on the home screen.
Post reply on HN