Opened 5 years ago

Last modified 5 years ago

#14830 new enhancement

dbus information leakage

Reported by: dfunc Owned by: bleeter
Milestone: Patches welcome Component: privacy
Version: 2.10.0 Keywords: libpurple dbus plugins
Cc: mark@…

Description (last modified by dfunc)

Pidgin transmits sensitive information (such as OTR plaintexts) over DBUS. Once this information is on DBUS there is no way to control which application receives it or what it does with it. This creates a privacy issue for OTR users.

Related posts: http://pidgin.im/pipermail/devel/2011-December/010519.html http://lists.cypherpunks.ca/pipermail/otr-dev/2011-December/001244.html

Change History (23)

comment:1 Changed 5 years ago by bleeter

  • Component changed from unclassified to libpurple
  • Keywords privacy added
  • Owner rekkanoryo deleted

Would seem to me that PURPLE_MESSAGE_NO_LOG would suggest no DBUS message type emissions should take place. But I suspect this may break Stuff.

comment:2 Changed 5 years ago by bleeter

  • Owner set to rekkanoryo

hmm, why did that post remove rekkanoryo as the owner? weird...

comment:3 Changed 5 years ago by bleeter

BTW, disclosure post by Dimitris Glynos with proof of concept code and CVE number, http://census-labs.com/news/2012/02/25/pidgin-otr-info-leak/

comment:4 Changed 5 years ago by bleeter

http://pastebin.com/Amu14mMj

In reply to: http://census-labs.com/news/2012/02/25/pidgin-otr-info-leak/ Pidgin is best sandboxed with AppArmor?/SELinux/other in any case but to avoid this specific issue with DBUS one may launch Pidgin like so: export DBUS_SESSION_BUS_ADDRESS=""; pidgin & This will stop Pidgin from registering with the DBUS server and the Proof Of Concept above will fail to log conversations.

comment:5 follow-ups: Changed 5 years ago by bleeter

Please note that whilst the information on the leak is correct, I believe the wrong 'product' has been labelled as the cause. Pidgin is the GTK UI that sits above libpurple. After a cursory look across the code, I believe any libpurple client using DBUS would also be exposed to this problem, not just Pidgin. There are patches out there for OTR to work with Finch, I've not tried it but I'd be surprised if it didn't have the same problem. Did you test these and were you able to confirm it's ONLY in Pidgin?

Here's a quick list of other products using libpurple. http://developer.pidgin.im/wiki/WhatIsLibpurple

Pete.

comment:6 in reply to: ↑ 5 Changed 5 years ago by dfunc

I have updated the advisory to reflect Peter's comments.

http://census-labs.com/news/2012/02/25/libpurple-otr-info-leak/

(old URL is still valid too)

I've also taken the liberty of mentioning that a fix for this is planned. Hope this is alright with you.

comment:7 follow-up: Changed 5 years ago by ultramancool

I don't think this is really a problem as if someone has access to your DBUS they most likely have local user access to your machine and could simply enable logging in your pidgin configuration, steal your OTR keys, use a debugger to break into the pidgin process and dump the text from it, etc. At the point someone has local access, all bets are off.

comment:8 in reply to: ↑ 7 Changed 5 years ago by dfunc

@ultramancool actually it is a problem. The heart of the problem lies in the fact that the iM has lost control over who has access to the OTR plaintext it just decoded. OTR is meant to be a "for-your-eyes-only" service. OTR plaintexts should not be logged (at least not without the user's consent) and should not be broadcasted in any way.

I am quite happy with the fact that your "all bets are off" mindset is not shared by many developers today who choose to correct local security bugs. Because well, they are bugs and do lead to trouble.

As far as process isolation goes, modern distributions disallow ptrace-ing processes that are not children of the debugger (see Ubuntu security provisions). So although we don't have perfect process isolation, there are steps taken in that direction (and for a good reason).

comment:9 Changed 5 years ago by ultramancool

@dfunc 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.

comment:10 Changed 5 years ago by dfunc

@ultramancool I hope you are a pidgin developer and I'm not losing my time here.

Please focus on the problem.

Once you broadcast sensitive info on DBUS, then you have *no control* where it goes or how it is being treated. You may apply a security policy on pidgin of not logging this info for example, but another application on the other end might choose not to adhere to this policy...

If you still feel strongly about this not being an issue we can discuss it over e-mail.

comment:11 Changed 5 years ago by MarkDoliner

  • Cc mark@… added; security@… removed
  • Milestone set to Patches welcome
  • Type changed from defect to enhancement

This issue isn't buffer overflow/remote code execution, and it isn't a crash/denial of service. I think it's even a bit of a stretch to call this a bug in libpurple--personally I'd describe it as missing functionality that is desired by a 3rd party plugin. And this issue by itself isn't even a problem--it's only a problem if your system has ALREADY been compromised. For these reasons I think a CVE number is a bit over the top. It doesn't seem like distributions need to track this issue outside of the normal Pidgin/libpurple release cycle. But I guess people have different expectations of how secure OTR should be.

It seems reasonable for us to add functionality to libpurple such that a plugin can specify that a message should not be broadcast over dbus. Then someone would need to change the OTR plugin to use this flag. And whether the flag is set should probably be configurable in OTR, since some users will want their OTR messages to be broadcast over dbus (for example, if they have a dbus app that watches for incoming IMs and shows a desktop notification).

comment:12 Changed 5 years ago by ultramancool

@dfunc I understand your perspective and I see that this should be fixed, I simply don't want to to see this drawn up like a security vulnerability as it's of no real risk. A friend showed me the report this morning and expressed concern over it when there is really little to no need for worry.

I'm not a pidgin dev and won't waste any more of your time, but I'm not sure this really merits a CVE or high priority and certainly not the concern of most Pidgin or OTR users.

comment:13 follow-up: Changed 5 years ago by bleeter

  • Owner changed from rekkanoryo to bleeter

@dfunc: Whether Ultramancool is a developer/patch writer for Pidgin or not is irrelevant. They raise some points that I feel should at least be discussed as this ticket is listed on your report.

If one's running OTR on a libpurple system where all 'bells and whistles' are compiled in, you've increased the surface area of attack by default. One shouldn't be surprised if Pidgin starts behaving in 'unusual' ways under such circumstances. For example, there's this https://www.guifications.org/issues/694#change-1962 with the LastSeen? plugin which I'm still to deal with, however I can't help but feel it's somehow related.

It's my opinion at the moment that OTR should at least perform a series of checks to see if the environment it's running in is protected against known issues (eg, see above with LastSeen? - at the moment, I believe OTR shouldn't activate if LastSeen? is enabled). Given there's no real 'trust' model for libpurple/pidgin/finch et al plugins, if I were an OTR dev I'd insist on not loading if ANY other plugins are enabled. I'd also not permit OTR to operate if DBUS were enabled. Something further that I've just thought of (but not investigated nor do I have inclination to), if the UI libpurple is connected to is performing spell checking, might it be possible for an attacker to glean information similarly to this attack? I use spell checking as an example, however I wish to emphasize this is more about exposing information to external support libraries.

And this is where I arrive at Ultramancool's comment #9.

There is something really odd about OTR's approach of implicitly trusting anything that Pidgin is capable of doing instead of, as I would try, to ensure the user has a very limited exposure. Still, fixing this properly will not be easy. Sure, we could suggest people disable DBUS, however that'll then disable NetworkManager support. Further, I could suggest OTR shouldn't be run in environments that permit plugins - however that obviously leads to the problem where OTR itself wouldn't be able to load.

As I've stuck my hand up for working in some regard on libpurple/pidgin/finch privacy, I've reassigned this ticket to me for now. I'm also in two minds as to whether this is a defect or an enhancement, or even in fact a Third Party issue (ok, three minds... nobody expects the Spanish Inquisition)

[this was written before #11 and independently from it, would seem to be some agreement yay!]

comment:14 Changed 5 years ago by bleeter

  • Component changed from libpurple to privacy
  • Keywords libpurple dbus plugins added; privacy removed

changing Component to new 'privacy' section and changing Keywords

comment:15 in reply to: ↑ 13 Changed 5 years ago by dfunc

@ultramancool: regarding the "being a developer" quote, I didn't mean this in a disrespecting manner and I hope I have not offended you. This ticket openned up last December and up until your response, there was no negative/positive statement as to whether this was going to be fixed or not by the pidgin devs. I'm not a lobbyist.. :-) so with the limited time I've got in my hands, I'm trying to reach pidgin devs first.

@MarkDoliner: CVEs are assigned for information leaks too.

Regarding updates, upstream may choose to publish fixes for bugs they consider as less risky along with normal updates. When distribution package maintainers have access to upstream's repository they sometimes group such bug fixes together to provide an interim package update, when the next official source release is a bit further down the road. So at the end of the day, both upstream and package maintainers reserve the right to choose when and how they will publish a fix. Personally, for this bug, I would not press for a quick fix, but I would like to see the developer team's commitment for the needed API change. And this change is much simpler in Pidgin than in other IMs because of its "loose" coupling with DBUS.

Please remember: CVEs are not there to scare developers. CVEs are there to track security issues in specific versions of software.

Regarding the API change, I agree that it should be up to the user to select if this information will or will not be broadcast over DBUS (with the default being no broadcast).

While reading your comments I see that you're mostly thinking this issue in terms of exploitation. But the main issue here is privacy. If a user opts out from logging OTR messages, then pidgin should be doing its part in making sure these messages don't end up on the filesystem (or swap) through 3rd party applications.

@bleeter: Let's deal with one issue at a time. Plugins should be able to flag information as private for starters. We can look at ways to enhance the OTR side of pidgin afterwards :-)

On a more personal note, I'd like thank everyone that has contributed to this discussion. Also big thank you's are due to the pidgin team for providing us with a great IM library & client.

comment:16 Changed 5 years ago by dfunc

  • Description modified (diff)

comment:17 Changed 5 years ago by dfunc

  • Description modified (diff)

comment:18 in reply to: ↑ 5 Changed 5 years ago by hyc

Replying to bleeter:

Please note that whilst the information on the leak is correct, I believe the wrong 'product' has been labelled as the cause. Pidgin is the GTK UI that sits above libpurple. After a cursory look across the code, I believe any libpurple client using DBUS would also be exposed to this problem, not just Pidgin. There are patches out there for OTR to work with Finch, I've not tried it but I'd be surprised if it didn't have the same problem. Did you test these and were you able to confirm it's ONLY in Pidgin?

Fyi, only pidgin looks for and connects to DBUS in its startup initialization. Finch does not.

Here's a quick list of other products using libpurple. http://developer.pidgin.im/wiki/WhatIsLibpurple

I haven't checked other apps to see what they do...

comment:19 Changed 5 years ago by bleeter

So it'd seem obvious that SILC would also be an issue with regards to this. If anyone would care to confirm/deny, would be appreciated.

comment:20 Changed 5 years ago by bleeter

Whilst we're working this and awaiting patches, etc., I'd suggest that anyone using OTR and Pidgin (and Adium) refrains from using OTR on Windows, OSX and a *nix windowed environment until such time as issues surrounding DBus, VNC, xwd et al can be resolved. If one wishes to reduce surface area of potential attack for Pidgin+OTR, seems the obvious thing to do is to help out with purple-otr (and use it with finch on, say, a Linux virtual terminal).

comment:21 follow-ups: Changed 5 years ago by MarkDoliner

bleeter: From your comment it almost sounds like you're suggesting that people not use OTR at all. Just to be clear, people's conversations are still WAY more private when using OTR than without it.

I really don't want people to get the wrong idea about this issue. People's conversations are still quite safe--this issue just means that if someone is able to gain access to your local user account then it is easier for them to see your conversations. (Of course, if someone has access to your local user account then you're basically screwed anyway.)

comment:22 in reply to: ↑ 21 Changed 5 years ago by dfunc

@bleeter MarkDoliner is correct in saying that people *are* more secure when communicating over a network using OTR. The main issue here is NOT remote exploitation or remote eavesdropping. The issue is that once your OTR messages enter DBUS many side effects might occur, like a 3rd party application *accidentally* logging these messages (because it couldn't distinguish these from normal non-OTR pidgin messages). And this is only partly due to the absence of the NO_LOG flag (for users that had selected "no" to logging). When broadcasting over DBUS, security policies for messages are applied in a "good citizen" approach. So it must be communicated to all receivers that these messages should receive special handling.

My proposal so far is:

  • To allow the user to select if OTR-messages should be broadcast over DBUS (with the default being "no broadcast")
  • An API change that will:
    • enable particular messages not to be broadcast over DBUS
    • make sure all security attributes of a message (e.g. NO_LOG) are sent along with the signal, when a message is transmitted over DBUS

Until the patch is released, users may choose to load pidgin with export DBUS_SESSION_BUS_ADDRESS="" as bleeter has suggested.

PS. The "census" article mentions exploitation strategies for this issue for reasons of completeness. Investigators must clearly know that it is also possible for an eavesdropper to catch OTR plaintext over DBUS. It seems that this information along with the original bugtraq post has caused a lot of confusion as to what this issue is all about... (i.e. unexpected privacy-related side-effects).

comment:23 in reply to: ↑ 21 Changed 5 years ago by bleeter

Replying to MarkDoliner:

bleeter: From your comment it almost sounds like you're suggesting that people not use OTR at all.

No, just (badly) stating the obvious a few ways how a fix for this is not a fix if your local user account is compromised and suggesting a method to limit this exposure. I felt it's important to clarify this point as such clarification had not really been made particularly in light of recent movements on 'purple-otr' that look quite useful.

I apologise for any confusion caused.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!