Project

General

Profile

Bug #14733

Pidgin no longer exposes plaintext messages / pidgin state through DBus

Added by maqp 22 days ago. Updated 22 days ago.

Status:
Rejected
Priority:
High
Assignee:
-
Category:
-
Target version:
Start date:
09/29/2017
Due date:
% Done:

0%

QA Check:
Dev Needed
Feature Branch:
Type of work:
Code
Blueprint:
Easy:
Affected tool:

Description

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

rikki.png View - Broken protocol converter application (120 KB) maqp, 09/29/2017 06:35 AM

History

#1 Updated by maqp 22 days ago

#2 Updated by intrigeri 22 days ago

  • 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 #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 22 days ago

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.

Also available in: Atom PDF