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

221–230 of 232 posts

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

#221

Post by charleslmunger »

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 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.

Yes, but most engineers would look at that last element and say "what on earth is going on here", where $.html() being dangerous is something that engineers who don't usually work on web might not know about. You're right about blaming the DOM spec, but there's no actual reason for signal desktop to interact with that poorly designed spec except that they chose electron as a framework.

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

#222

Post by bigiain »

lmm wrote: post #189
bigiain wrote: post #94

Earlier quoted context omitted.

Signal runs just fine on an iPod Touch (after a little fussing around getting it set up with a phone number...) If you're paranoid enough, it's easy enough to avoid installing things that're likely to be crapware on your secure comms device. Apart from Signal, the only other non iOS supplied apps I have installed on mu iPod are a bitcoin wallet and Onion Browser - both of which I angst a little about, since they're b…

If you're willing to adopt "run a dedicated device for crypto" approach, something like Tails running on a USB-key-like device gives you the same kind of security position and without having to trust Apple.

Yeah, I do that too (and an offline wallet on a RasPi which has never been internet connected) - but for secure messaging and for some bitcoin transactions, I want that device in my pocket. I treat the iPod cryptocurrency wallet like, well, a wallet - containing amounts I feel comfortable carrying around (like the couple of hundred in cash I might have in my wallet at any time). I "trust" Apple enough to store that. I wouldn't treat the iPod as a bank, storing significant or lifechanging amounts of value.

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

#223

Post by JepZ »

pfg wrote: post #205
JepZ wrote: post #199

Earlier quoted context omitted.

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

Signal merged support for devices without Play Services about a year ago. Is that what you're looking for?

In fact I am not looking for anything, as I am using conversations, but any unnecessary use of (Google) services is something I consider not privacy friendly, even if it is used just as signaling channel.

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

#224

Post by mercer »

grrowl wrote: post #121
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 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.

Why is this a 404 now?

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

#225

Post by wolf550e »

ianopolous wrote: post #115
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.

What about qubesOS?

Not mainstream, and there must be a reason why. I guess ease of use, though I don't know.

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

#226

Post by Stephen304 »

mercer wrote: post #224
grrowl wrote: post #121

Earlier quoted context omitted.

> 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.

Why is this a 404 now?

Looks like grrowl copied and repasted the truncated display text of the link. The full link is 2 comments up: https://github.com/signalapp/Signal-Desktop/commit/9d41b8616...

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

#227

Post by jhasse »

camgunz wrote: post #210
jhasse wrote: post #200

Earlier quoted context omitted.

Care to give an example?

strcat (or, honestly, anything in string.h). strcat assumes its first argument has enough allocated space for the contents of the 2nd argument, and that the 2nd argument is NULL terminated. If either of those assumptions is wrong, strcat will overwrite memory, corrupting either your heap or your stack, both of which can lead to arbitrary code execution. It's laughably easy to do, so easy that even typing the letters…

strcat is C and not C++ though.

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

#228

Post by ccnafr »

rando444 wrote: post #207
ccnafr wrote: post #187

Earlier quoted context omitted.

I was referring to the fact of imitating the HN brand by capitalizing on the domain name so they could scoop up all the traffic and SEO love. That's why the domain was banned to begin with a few years back. There was a whole discussion about it.

The site that I was referring to was literally hackernews.com, and was very popular among the tech crowd from the late 90s onward. (long before YC was conceived) ALmost 20 years ago, I used to rotate between hacker news, fark, and slashdot to get my daily dose of internet. https://web.archive.org/web/*/hackernews.com One would be perfectly justified in also trying to claim that the name here was stolen from the origi…

Not that one. That's owned by Space Rogue. I'm talking about the one linked now, owned by some Indians who keep copying articles off other sites. There was a reason this got banned years ago. At one point you could trace articles from The Register and Motherboard paragraph by paragraph to their stories, but with bad grammar and bad sentence structure.

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

#229

Post by camgunz »

jhasse wrote: post #227
camgunz wrote: post #210

Earlier quoted context omitted.

strcat (or, honestly, anything in string.h). strcat assumes its first argument has enough allocated space for the contents of the 2nd argument, and that the 2nd argument is NULL terminated. If either of those assumptions is wrong, strcat will overwrite memory, corrupting either your heap or your stack, both of which can lead to arbitrary code execution. It's laughably easy to do, so easy that even typing the letters…

strcat is C and not C++ though.

Nah it's both. C++ was deliberately designed to be a superset of C. It's diverged a little bit, but it's mostly still the case. Or, call it `std::strcat` if you like.
Post reply on HN