Another flaw in Signal desktop app leaks chats in plaintext
151–160 of 232 posts
Re: Another flaw in Signal desktop app leaks chats in plaintext
#152Re: Another flaw in Signal desktop app leaks chats in plaintext
#153Earlier 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)?
Re: Another flaw in Signal desktop app leaks chats in plaintext
#154Maybe 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…
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
#155Someone invited me to use signal. I thought "It's a trap!"
Re: Another flaw in Signal desktop app leaks chats in plaintext
#156Is 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.
Re: Another flaw in Signal desktop app leaks chats in plaintext
#157Earlier 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)?
Re: Another flaw in Signal desktop app leaks chats in plaintext
#158Earlier 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…
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
#159What is this website? "The Hacker News"? And no actual relation to HN? This website doesn't even have an about page...
Re: Another flaw in Signal desktop app leaks chats in plaintext
#160I 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…