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

201–210 of 232 posts

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

#201

Post by ddtaylor »

Cakez0r wrote: post #197
ddtaylor wrote: post #104

Earlier quoted context omitted.

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!

These are the kinds of things that make tinfoil hats wonder if any agencies interested in subverting encryption "plant" employees. It's difficult to differentiate stupidity from malice. We know they use shell companies and subvert device manufacturers and standards, so it's not unfathomable.

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

#202

Post by kuroguro »

jscissr wrote: post #190
hawkice wrote: post #186

Earlier quoted context omitted.

Which raises the best question: how would you exploit someone not escaping single quotes? I do not know. Perhaps it isn't possible.

I think escaping quotes only matters for attributes (which can use ' or "). Example: Exploit: foo.jpg" onload="alert('pwned')

Heh, found the exact bug on a live bbcode parser some 5 years ago.

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

#203

Post by belorn »

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.

This is easily proven false by simply looking at professionals which either by necessity or regulation require a strict secure environment.

How common is it that the military use iphone apps for classified information or to interface with military equipment. Do operators in powerplants or other sensitive infrastructure use iphone apps as interface to their systems. When security is a primary objective then having it hooked up with a third-party that continuously collects information that you have no control over sounds as a very bad security recommendation, especially when it has a independent GPS, GSM, and network capability which bypass normal network security tools.

If signal crashes and a crash report is generated, who get access to it on a iphone? Who might get a potential memory dump with plaintext? If that party is apple I would strongly recommend that one is first okey with the idea that apple has access to the plaintext before using such app.

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

#205

Post by pfg »

JepZ wrote: post #199
def_true_false wrote: post #182

Earlier quoted context omitted.

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.

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

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

#206

Post by _emacsomancer_ »

fjsolwmv wrote: post #138
_emacsomancer_ wrote: post #119

Earlier quoted context omitted.

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

And as the old saying continues, "...so instead you invented a proprietary one, with hidden code, and told everyone it's secure."

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

#207

Post by rando444 »

ccnafr wrote: post #187
rando444 wrote: post #183

Earlier quoted context omitted.

I don't see anything imitating this website.. other than a technology based news feed and a similarly used name. I used to browse a website called "hacker news" back in the late 90s / early 2000s, but I wouldn't go as far as to call News YC a copy of that.

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

.. but sometimes, just because things share a common name, does not necessarily mean they are related.

https://en.wikipedia.org/wiki/Post_hoc_ergo_propter_hoc

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

#208

Post by tptacek »

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…

No, it's because end-users don't adopt 2FA via TOTP and, to a first approximation, nobody uses U2F. It's not a corner security teams are cutting. Microsoft's security team makes the same decisions.

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

#209

Post by AnaniasAnanas »

tptacek wrote: post #21
4ad wrote: post #14

Earlier quoted context omitted.

The PGP vulnerability is actually in e-mail clients, and it affects almost nobody. And how often do PGP vulnerabilities happen? Signal got two vulnerabilities that affect everyone JUST THIS WEEK .

By "almost nobody", you mean everyone who used Apple Mail/GPGTools and Thunderbird/Enigma, meaning, the vast majority of everybody who used PGP?

Enigmail 2 was not affected.

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

#210

Post by camgunz »

jhasse wrote: post #200
jrockway wrote: post #195

Earlier quoted context omitted.

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?

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` into your program is forbidden in basically every C/C++ shop.
Post reply on HN