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

191–200 of 232 posts

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

#191

Post by kasey_junk »

mbid wrote: post #168
kasey_junk wrote: post #95

Earlier quoted context omitted.

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?

That’s functionally harder in most cases than just inspecting the binary.

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

#192

Post by pmlnr »

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.

Just go XMPP with OMEMO or Matrix.

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

#193

Post by detaro »

tptacek wrote: post #29
detaro wrote: post #28

Earlier quoted context omitted.

And we're back at "really good security is to inconvenient to use" :/

This is a rare case where things are inconvenient for nerds to use, but more convenient for ordinary people, who tend to be more comfortable doing stuff on mobile platforms than nerds are.

Is that also true for professional use? For private use/relatively few threads I'd agree with that, the insistence on IM on desktop is a niche, but I'd think most people using chat a lot professionally (e.g. Slack) do not use it mobile-only. And if you'd want them to shift communication away from e-mail, it gets even more important.

(as p49k alluded to, iPads help, but few professional users have them as the primary device)

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

#194

Post by kbwt »

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/

The native code (RedPhone remnants?) did not inspire confidence last I looked at it.

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

#195

Post by jrockway »

lnrdgmz wrote: post #122
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.

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

I mean, in C++ "=" could be called "dangerouslySetAribtraryMemoryLocation" and it would be just as accurate. In native code, even trivial operations like concatenating two strings or setting a variable can cause arbitrary code to execute.

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

#196

Post by komuW »

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…

Is there a linter that can catch this kind of mistakes?

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

#197

Post by Cakez0r »

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

Even worse than that, it looks like there _were_ unit tests to check that input was correctly sanitized, but the patch that introduced the bug also explicitly changed the unit tests to ensure that input was _not_ being escaped!

A mistake that seems like it could've been caught in a code review!

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

#198

Post by pvg »

lawnchair_larry wrote: post #158
tptacek wrote: post #148

Earlier quoted context omitted.

I don't know what the first iPhone to have an HSIC baseband was, but it has been awhile. I assume every iPhone anyone is really using today fits the description I gave. The iPhone 4 does. This is a really basic security design concern for mobile devices; you can assume that neither Apple nor Google (for their own Google-branded phones) ships products where a corrupted baseband can simply DMA its way into the AP. It i…

"It is a little weird to me that people on message boards assume they've outguessed the hardware security teams at both Apple and Google on one of the most obvious attack vectors for their phone designs; both companies spend huge amounts of money on this stuff." For what it's worth, that isn't the assumption people are making. The easy assumption to make is that the security teams were unable to convince product owne…

it's not because the security team doesn't know

It's also not because they don't think it's 'worth the investment' or due to extra expense.

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

#199

Post by JepZ »

def_true_false wrote: post #182
al_chemist wrote: post #44

Earlier quoted context omitted.

> don't use desktop secure messengers at all. Desktop applications are incredibly risky, far more so than iOS mobile apps are. It's risky to use an open source OS. If you are serious about security, use Android or iOS. Instead of direct ssl connection to XMPP server, it's much safer to send all your data with Google Cloud Messaging. /s Desktop computers are currently the most open sourced, least opaque, least spyware…

I'm pretty sure Signal doesn't send all your data through GCM. Edit: https://support.signal.org/hc/en-us/articles/217524107

Its sad enough they use GCM at all. Android Apps can works perfectly well without GCM.

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

#200

Post by jhasse »

jrockway wrote: post #195
lnrdgmz wrote: post #122

Earlier quoted context omitted.

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

I mean, in C++ "=" could be called "dangerouslySetAribtraryMemoryLocation" and it would be just as accurate. In native code, even trivial operations like concatenating two strings or setting a variable can cause arbitrary code to execute.

Care to give an example?
Post reply on HN