Bug #14733
Pidgin no longer exposes plaintext messages / pidgin state through DBus
0%
Description
Regarding Bug #14612
Quoting “ultramancool” in the upstream ticket:
>It’s ridiculous to try to fix an issue where the user must be completely compromised in order to have, because then everything is an issue. How hard would it really be for an attacker to simply kill your pidgin process and restart it with a custom LD_PRELOAD? Not to mention gtkparasite or similar could easily be used to grab the messages from the pidgin window, as could common screenshoting tools. When an attacker can execute code, all bets are off, you simply cannot fix this sort of issue no matter how you pursue it. The only way to protect against this would be complete and total desktop and process isolation, which are things we simply do not have right now. This is not “security” this is simple obscurity. Obscuring the problem does not solve it.
I’ve been working on a high assurance solution for endpoint secure messaging since 2012 and for that, DBus IO for OTR plaintext messages is a feature, not a bug; TFC (https://github.com/maqp/tfc) is a HW/SW messaging system that encrypts/decrypts messages on external computers, that is, physically separated from networked computer running Tails. The ciphertexts are exchanged between computers using hardware data diode enforced, unidirectional serial interfaces and a protocol converter program that talks to Pidgin using DBus. This approach entirely solves the issue of key/pt exfiltration from compromised Tails (Read the GitHub readme for more details). You can observe the interaction of the three computers here:
The fix for Bug #14612 has completely broken IO between application in Terminal (NH) and Pidgin. Please either re-enable DBus for Pidgin, or help me add necessary commands to installer that re-enable DBus for TFC users.
Files
Subtasks
History
#1 Updated by maqp 2017-09-29 06:36:00
- File rikki.png added
#2 Updated by intrigeri 2017-09-29 08:33:40
- Status changed from New to Rejected
Hi,
> It’s ridiculous to try to fix an issue where the user must be completely compromised in order to have, because then everything is an issue. How hard would it really be for an attacker to simply kill your pidgin process and restart it with a custom LD_PRELOAD?
At least the apps we confine with AppArmor won’t be able to do so.
> Not to mention gtkparasite or similar could easily be used to grab the messages from the pidgin window, as could common screenshoting tools. When an attacker can execute code, all bets are off, you simply cannot fix this sort of issue no matter how you pursue it. The only way to protect against this would be complete and total desktop and process isolation, which are things we simply do not have right now. This is not “security” this is simple obscurity. Obscuring the problem does not solve it.
All this is correct in theory but it requires the attacker do be more sophisticated and to target their attack a bit more. We have mid+long-term plans to provide better desktop apps isolation (starting with Feature #12213 and longer-term Flatpak/Portals/bubblewrap -like stuff) but that should not prevent us from blocking low-hanging attack vectors we can easily block now without causing too much pain.
> I’ve been working on a high assurance solution for endpoint secure messaging since 2012 and for that, DBus IO for OTR plaintext messages is a feature, not a bug; […]
I’m glad you’re building on top of Tails. To assess the actual impact of the contested change, do you have any idea of the size of the userbase of tfc? It’s the first time I hear about this and the entry bar seems pretty high so I guess it’s only used by a small set of rather technical users with very high security requirements. Correct?
Note that the contested change was in Tails 3.2~rc1. I would suggest you follow change in parts of Tails that you rely upon a bit closer, starting with testing our release candidates :) Now, I doubt we would have changed our mind but at least we would have had a more relaxed conversation rather than a “high priority” ticket.
> help me add necessary commands to installer that re-enable DBus for TFC users.
rm /etc/dbus-1/session.d/im.pidgin.purple.PurpleService.conf should be enough.
#3 Updated by maqp 2017-09-29 08:56:26
> I’m glad you’re building on top of Tails. To assess the actual impact of the contested change, do you have any idea of the size of the userbase of tfc? It’s the first time I hear about this and the entry bar seems pretty high so I guess it’s only used by a small set of rather technical users with very high security requirements. Correct?
I agree the tool is intended for more technical users. As for the size of userbase, I have absolutely no idea, as it should be.
> Note that the contested change was in Tails 3.2~rc1. I would suggest you follow change in parts of Tailthat you rely upon a bit closer, starting with testing our release candidates :)
That’s great advice. Thanks, I’ll do that!
> rm /etc/dbus-1/session.d/im.pidgin.purple.PurpleService.conf should be enough.
Great, thanks! I also discovered this minutes ago (used mv instead of rm). I’m glad the fix was as easy as that, and that non-TFC users now have more security with Tails.
The ticket can now be closed.