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

161–170 of 232 posts

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

#161

Post by icebraining »

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

Maybe he did and it didn't work for some reason and he thought it was good. Shit happens. I think the most worrying part is not having been caught in code review. Signal does code review, right?

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

#162

Post by kilburn »

burtonator wrote: post #154
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…

One thing I'd like to see is more use of containers and permissions locally. For example, my IntelliJ runs as my user account, but it doesn't need access to all my files. I should be able to select which directories it has access to and it's within a container by default. I mean I can set this stuff up manually, but in the future I'd like to see this as the default. Similar to the way Android apps ask for permissions…

It seems you are calling for Qubes OS [1], which does that but using VMs (which should be more secure than containers).

It will take a looong time for "standard" OSes to get there, if they ever do. The required changes in UX are very significant...

[1] https://www.qubes-os.org/

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

#163

Post by pjmlp »

burtonator wrote: post #154
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…

One thing I'd like to see is more use of containers and permissions locally. For example, my IntelliJ runs as my user account, but it doesn't need access to all my files. I should be able to select which directories it has access to and it's within a container by default. I mean I can set this stuff up manually, but in the future I'd like to see this as the default. Similar to the way Android apps ask for permissions…

That is the whole idea of the UWP model on Windows, and the ongoing work to put Win32 apps inside of the same containers.

Or the sandbox models on Android, iOS and macOS.

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

#164

Post by aidenn0 »

tptacek wrote: post #43
08-15 wrote: post #38

Earlier quoted context omitted.

Care to explain? I mean, in principle. I distrust Signal Desktop, whether it's built on Chrome or on Electron, because either of those "platforms" are more complex than my OS (Debian GNU/Linux). But you seem to be making a more general point... what's the reasoning?

No matter what Signal does with Desktop, it will remain a standard desktop application, meaning it will in general be as secure as the least secure application sharing that desktop.

Is there currently any desktop application delivery/sandboxing mechanism that has any hope of changing this situation in the future?

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

#165

Post by icebraining »

08-15 wrote: post #68
dasyatidprime wrote: post #59

Earlier quoted context omitted.

What are you using for X security context isolation? I've been wanting a good solution for that one for a while now, and the end of my list is still “write my own isolating proxy” since I never found a good one.

Nothing... but can X11 applications actually steal data from each other? I wouldn't know how to do that, but I know precious little about the X11 protocol. (Screen shots are an awkward option, I guess.) If I was worried enough (I'm not), I could use multiple logins. Two different X servers under different users would be completely isolated.

Even using two X servers under two logins, the fact is that desktop apps by default have much more freedom and therefore much more surface to attack. Even the kernel syscalls alone are not safe; exploits that elevate processes to root are not rare. You'd need to lock them down much more than just using different users.

By the way, they may have an history, but nowadays I wouldn't bet on the security of the average distro vs Windows, and I say this as a dyed-in-the-wool Debian user. For example, their Desktop environment does have protections against cross-application attacks, unlike X.

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

#166

Post by pauldino »

ddtaylor wrote: post #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 seem…

It looks like those are 3 separate third-party libraries (Mocha, Mustache, and Backbone), so each doing HTML escaping a bit differently shouldn't be too surprising.

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

#167

Post by soziawa »

verroq wrote: post #93

Is there a native Signal client that isn’t an Electron abomination? It is clear at the point the Signal desktop people has no idea what they are doing and cannot be trusted to write a secure desktop application.

Nope. But you can try Threema or Wire. They're both pretty good.

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

#168

Post by mbid »

kasey_junk wrote: post #95
4ad wrote: post #32

Earlier quoted context omitted.

Desktop applications are incredibly risky, yes; as for iOS mobile apps we can't even know, as these devices don't allow auditing what software is running on them. PGP has many problems and I hope a better replacement will come along, but the first step of secure messaging can't be using devices with closed, unauditable software...

A reason you are getting downvotes is that it’s not true that closed source software is unauditable. This is a common but untrue belief. It’s a fundamental axciom of software security that you can’t trust source, so you must diagnose the binary. Source may be helpful, but in the grand scheme of things lots of other properties are more important.

> It’s a fundamental axciom of software security that you can’t trust source, so you must diagnose the binary.

What if you trust the build tool chain and can reproduce the binary from source?

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

#169

Post by microtonal »

pjmlp wrote: post #163
burtonator wrote: post #154

Earlier quoted context omitted.

One thing I'd like to see is more use of containers and permissions locally. For example, my IntelliJ runs as my user account, but it doesn't need access to all my files. I should be able to select which directories it has access to and it's within a container by default. I mean I can set this stuff up manually, but in the future I'd like to see this as the default. Similar to the way Android apps ask for permissions…

That is the whole idea of the UWP model on Windows, and the ongoing work to put Win32 apps inside of the same containers. Or the sandbox models on Android, iOS and macOS.

And Flatpak on Linux. IIRC the Signal Flatpak is sandboxed.

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

#170

Post by Rjevski »

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…

I disagree; the issue is Electron.

Sure, you can write secure apps in Electron, just like you can do risky stuff in real-life and be fine most of the time. But why take the risk?

Had the app been written with a native language and SDK, they wouldn’t need to worry about escaping or anything. I have yet to hear about getting remote code execution for dumping text into an UILabel or similar, while XSS happens almost every day.

Post reply on HN