It's mind boggling why messaging app has 181 MB.
Another flaw in Signal desktop app leaks chats in plaintext
171–180 of 232 posts
Re: Another flaw in Signal desktop app leaks chats in plaintext
#172Earlier 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.
What's incredible is that the author actually had to modify an XSS test so that it read:
> const expected: string = "Hello
alert('evil');World!";
(Meaning they actually changed a line that had "alert('evil')" and didn't notice.)
I have seen this before though, with some folks removing path sanitisation code I added several years prior to fix a CVE. So it's not uncommon (it also got merged, so when I found out and fixed it I added a very large and scary comment to stop people from doing it again).
Re: Another flaw in Signal desktop app leaks chats in plaintext
#173It's mind boggling why messaging app has 181 MB.
I'm really starting to get tired of all these bloated JavaScript desktop apps. I get that it's more convenient for developing cross-platform apps with modern looking UIs, but I really wish there would be an increased focus on reducing the overall bloat and resource use, both among app and framework devs.
Speaking as a Windows user, I would vastly prefer a well-designed native application (WinForms/WPF) over a JS monstrosity any day.
Re: Another flaw in Signal desktop app leaks chats in plaintext
#174From the researcher who found it:
we were able to compile a list of strategic defense-in-depth recommendations for Signal Desktop which we’ve sent to the Signal security team per their request. At the end of the day there will always be new “hot” vulnerabilities, but the “vendor” response is generally what separates the wheat from the chaff. The Signal team’s quick patch time along with a strong interest in mitigating vulnerabilities of this type in the future was encouraging to see. I’ll remain a Signal user for the foreseeable future :)
https://thehackerblog.com/i-too-like-to-live-dangerously-acc...
Re: Another flaw in Signal desktop app leaks chats in plaintext
#175Earlier quoted context omitted.
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?
Wayland, the xdg-apps sandboxing (now FlatPak), containers in general, etc.
Re: Another flaw in Signal desktop app leaks chats in plaintext
#176Earlier quoted context omitted.
> 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 ;)
No, analogously to adding a script tag with jQuery, I meant adding a script tag, with javascript inside, to the innerHTML of some other element.
Re: Another flaw in Signal desktop app leaks chats in plaintext
#177This news saddens me. I’ve been the last user of the Signal desktop app around me and it looks like I have been too optimistic about Electron. I’ve now deleted any Electron app and recommend everyone to do the same.
Re: Another flaw in Signal desktop app leaks chats in plaintext
#178Wasn't this domain imitating the actual Hacker News banned years ago?
Plus, I think they violate rules because this is just blog spam.
The actual source of the story is: https://ivan.barreraoro.com.ar/signal-desktop-html-tag-injec...
Re: Another flaw in Signal desktop app leaks chats in plaintext
#179Earlier quoted context omitted.
Doesn't that answer assume some or all of the following? a) Apple does a better job reviewing apps than Debian maintainers do. b) iPhone app code is better quality than Debian packages. c) iOS sandboxing is better than Linux. Default configuration may mean c) is true. However not if you use wayland, apparmor, seccomp, namespaces etc. What do you think about a) and b)?
The beep local root suggests the Debian review system has room to improve. It's a pretty deep barrel. You're sure there's no crud at the bottom?
beepmargeddon is a local privilege exploit, not a RCE.
I'm not aware of any debian package (I don't use debian that often though so mind that) that A) installs a network service and B) uses unsafe defaults while C) activating the service on boot by default
Re: Another flaw in Signal desktop app leaks chats in plaintext
#180Earlier quoted context omitted.
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.
So all code is a huge problem? Makes sense to me.