Live data from Hacker News

Another flaw in Signal desktop app leaks chats in plaintext

thehackernews.com

151–160 of 232 posts

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

#152
Interesting, more or less, nothing is 100% secure. Looks like DEA had cracked the whatever crypto Blacberry was using and quite a few drug dealers were caught that way (one example: https://www.thedailybeast.com/the-deas-dirty-cop-who-tipped-... ). They must have been using because of the reputation BB had. I wonder what will we find out in time about the narcos, terrorists etc using Signal.

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

#153

Earlier quoted context omitted.

You will be in worse shape than I will be. It's possible, in that insane proposition, that your Debian machine will be conceding remote code execution to the whole Internet, while my phone will just have some crappy apps on the home screen.

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 question wasn't whether they could write an elaborate seccomp policy to contain any given Debian package. I just got to pick 10 of them, and install them.

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

#154
post #9
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…

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.

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

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

You can run it as a chrome extension, which I do, in a dedicated VM.

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

#157

Earlier quoted context omitted.

You will be in worse shape than I will be. It's possible, in that insane proposition, that your Debian machine will be conceding remote code execution to the whole Internet, while my phone will just have some crappy apps on the home screen.

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?

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

#158

Earlier quoted context omitted.

That's good to know (and for almost anybody else I'd add "citation needed"...) Didn't the iPhone baseband processor at some time in the past have dma? I vaguely recall a perhaps Usenix paper that seemed to claim any phone that had a software unlock where you could disable the carrier locking, was almost certainly using dma connections between the baseband and AP. Any hints or links or search terms which would show me…

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 owners at these companies that the extra expense of solving this was worth their investment. Especially because practical baseband attacks still haven't hit them as an issue, and it's very rare for product owners to take on major changes or invest in security for "theoretical" threats.

Just look at all of the services still allowing SMS for 2FA - it's not because the security team doesn't know that is an insane thing to be doing in 2018.

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

#160

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…

The first one doesn't escape single quotes or slash, but I have no idea how to get any HTML parser to treat just those as anything but text. Underscore's implementation will be correct, I'm sure.
Post reply on HN