Opened 9 years ago

Closed 5 years ago

Last modified 12 months ago

#1676 closed defect (invalid)

Audit jabber/XMPP support for pidgin

Reported by: katmagic Owned by: ioerror
Priority: Medium Milestone:
Component: Archived/Tor Messenger Version:
Severity: Blocker Keywords: pidgin, DNS, needs-triage
Cc: intrigeri, tor@…, rubin@…, proegssilb@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by ioerror)

Pidgin leaks DNS requests when using the XMPP protocol.

When Pidgin connects to an XMPP server, it makes a DNS request using the system's resolver.

This is also our general ticket for auditing Jabber/XMPP support in Pidgin - if we find that it's safe, we'll be ready to enable it in TIMBB again.

Child Tickets

Attachments (3)

jabber.c-dns.patch (2.5 KB) - added by ioerror 9 years ago.
a quick hack example
jabber.h-dns.patch (611 bytes) - added by ioerror 9 years ago.
pidgin-gtalk-dns-queries-2011-05-26-01-summary-lines.txt (1.3 KB) - added by rransom 8 years ago.

Download all attachments as: .zip

Change History (53)

comment:1 Changed 9 years ago by rransom

Owner: changed from erinn to ioerror
Status: newassigned

comment:2 Changed 9 years ago by ioerror

I've found that this bug is actually related to how Pidgin handles configured files. I've filed this bug upstream and the pidgin developers were not really too helpful. I think they think it is a minor issue.

comment:3 Changed 9 years ago by ioerror

Owner: changed from ioerror to helix

comment:4 Changed 9 years ago by ioerror

Here's the bug report that I filed with Pidgin: http://developer.pidgin.im/ticket/11110

comment:5 Changed 9 years ago by rransom

Owner: changed from helix to erinn

If the Pidgin developers don't fix this -- and it looks to me like they either don't care or don't understand that leaking DNS requests when a proxy is specified is a security hole -- then we have several options:

  1. write a patch for Pidgin ourselves, and patch Pidgin in TIMBB and/or shove the patch upstream
  2. stop shipping Pidgin's XMPP plugin in TIMBB
  3. replace Pidgin in TIMBB with less broken IM/IRC clients
  4. stop shipping TIMBB and explain why on the blog

comment:6 in reply to:  5 Changed 9 years ago by phobos

Replying to rransom:

If the Pidgin developers don't fix this -- and it looks to me like they either don't care or don't understand that leaking DNS requests when a proxy is specified is a security hole -- then we have several options:

  1. write a patch for Pidgin ourselves, and patch Pidgin in TIMBB and/or shove the patch upstream
  2. stop shipping Pidgin's XMPP plugin in TIMBB
  3. replace Pidgin in TIMBB with less broken IM/IRC clients
  4. stop shipping TIMBB and explain why on the blog

I vote for #4.

comment:7 Changed 9 years ago by erinn

#4 sounds good to me, though I sincerely hope it is merely suspended rather than canceled while we sort out one of the other solutions. We definitely should not continue to ship something that endangers our users.

We should make sure to direct the angry hordes to the Pidgin bug too. :) By "we" I mean "me", when I write the blog post.

comment:8 Changed 9 years ago by T(A)ILS developers

Cc: amnesia@… added

comment:9 Changed 9 years ago by T(A)ILS developers

There has been some activity on the upstream bug recently: a long-time Pidgin contributor reopened the bug and stated s/he intended to look at it and "bang out some kind of temporary fix".
Hope, hope.

comment:10 in reply to:  9 Changed 9 years ago by rransom

Replying to T(A)ILS developers:

There has been some activity on the upstream bug recently: a long-time Pidgin contributor reopened the bug and stated s/he intended to look at it and "bang out some kind of temporary fix".

It's not fixed yet. We should stop shipping Pidgin's XMPP plugin, if not Pidgin or TIMBB, until this bug is actually fixed (and the fix is reviewed by someone we trust).

#1325 is also relevant to a discussion of whether or not to continue shipping Pidgin and/or TIMBB.

comment:11 Changed 9 years ago by rransom

Priority: normalcritical

There have been no further updates to the Pidgin bug since comment 16, currently 8 weeks ago. Do we fix Pidgin, toss Pidgin's XMPP plugin, or toss Pidgin?

comment:12 Changed 9 years ago by ioerror

I think it is the wrong approach to kneecap our users by pulling TIMBB without public notice. I am going to work on fixing this in Pidgin on Linux if I can repro the bug with a current copy of Pidgin (pidgin-2.7.11) - I guess my patch will fix it for our users but I doubt it will be accepted upstream.

comment:13 Changed 9 years ago by ioerror

I am building this on Linux with the following configure arguments:

 ./configure --disable-screensaver --disable-gstreamer --disable-vv --disable-idn --disable-meanwhile --disable-dbus --disable-perl --disable-tcl --enable-gnutls=no --enable-nss=yes --disable-consoleui
time make

This produces a Pidgin and I will use this as the basis for my work.

comment:14 Changed 9 years ago by ioerror

I've also built pidgin-otr plugin to be included: http://www.cypherpunks.ca/otr/pidgin-otr-3.2.0.tar.gz

comment:15 Changed 9 years ago by ioerror

It is not safe to use the voice and video functionality with Tor. It breaks out of the proxy.

comment:16 in reply to:  description ; Changed 9 years ago by DrWhax

Replying to katmagic:

When Pidgin connects to an XMPP server, it makes a DNS request using the system's resolver.

A small and temporary fix for linux based distro's to fix dns leaking when using the XMPP protocol: http://drwhax.tumblr.com/post/4507494688/pidgin-and-tor

comment:17 in reply to:  16 Changed 9 years ago by ioerror

Replying to DrWhax:

Replying to katmagic:

When Pidgin connects to an XMPP server, it makes a DNS request using the system's resolver.

A small and temporary fix for linux based distro's to fix dns leaking when using the XMPP protocol: http://drwhax.tumblr.com/post/4507494688/pidgin-and-tor

While it's a useful work around, it's not likely that any TBB or TIMBB user will be able to do this without administrative rights.

comment:18 Changed 9 years ago by ioerror

The above patch might stop the actual DNS leaks in jabber - the rest of pidgin is gonna take a LOT of work.

Changed 9 years ago by ioerror

Attachment: jabber.c-dns.patch added

a quick hack example

Changed 9 years ago by ioerror

Attachment: jabber.h-dns.patch added

comment:19 Changed 9 years ago by ioerror

These patches appear to fix the leaks in http://developer.pidgin.im/ticket/11110 for jabber related DNS leaking.

Can someone please test this patch?

comment:20 Changed 9 years ago by ioerror

Parent ID: #2918

comment:21 Changed 9 years ago by ioerror

Owner: changed from erinn to ioerror

comment:22 Changed 9 years ago by ioerror

Description: modified (diff)
Summary: Pidgin leaks DNS requests when using the XMPP protocol.Audit jabber/XMPP support for pidgin

comment:23 Changed 8 years ago by erinn

I tested the latest Pidgin release (2.8.0) with the Tor proxy option added and while it can be set globally, you can only force encrypted logins on a per-account basis. Robert pointed out on IRC that it would be difficult to have a globally set option for this in Pidgin because of the variation in protocol specificities, but we should ask the Pidgin developers if there's any way to pre-seed it for a few IM types (our initial re-integration ones: GTalk, AIM, and XMPP), either by having a dummy accounts.xml or some other way.

comment:24 Changed 8 years ago by rransom

Now that we can tell Pidgin to never perform direct (unproxied) DNS SRV queries, we need to either (a) teach Pidgin to perform the SRV query it needs for XMPP using DNS-over-TCP over Tor (and pick a TCP-capable DNS server for Pidgin to use, so it won't connect to the user's system-wide DNS resolver (i.e. the user's ISP) over Tor), or (b) provide a separate tool to perform the required SRV query and tell users how to feed the results to Pidgin and tell users how to find and use that tool.

If we decide to provide a separate tool (possibly as a stopgap solution), the DNS SRV query is for the ‘hostname’ _xmpp-client._tcp.gmail.com, and the resulting hostname and port go in the ‘Connect server’ and ‘Connect port’ fields, respectively, on the ‘Advanced’ tab of Pidgin's account settings dialog. (I don't know how to parse the hostname and port out of the SRV reply.)

See pidgin-gtalk-dns-queries-2011-05-26-01-summary-lines.txt for a Wireshark packet-summary dump of Pidgin performing the SRV query required for an XMPP account on gmail.com.

comment:25 Changed 8 years ago by ioerror

I think that we don't need to write anything new - we simply do not support XMPP related DNS SRV requests at this time.

comment:26 in reply to:  23 Changed 8 years ago by ioerror

Replying to erinn:

I tested the latest Pidgin release (2.8.0) with the Tor proxy option added and while it can be set globally, you can only force encrypted logins on a per-account basis. Robert pointed out on IRC that it would be difficult to have a globally set option for this in Pidgin because of the variation in protocol specificities, but we should ask the Pidgin developers if there's any way to pre-seed it for a few IM types (our initial re-integration ones: GTalk, AIM, and XMPP), either by having a dummy accounts.xml or some other way.

I use hidden services that do not support SSL. It would be nice if it was turned on by default but I need the option to use "insecure" services when I actually know better than Pidgin could ever know.

comment:27 Changed 8 years ago by ioerror

asn said he'd look into this as a possible issue:
http://sock-raw.org/papers/abusing_network_protocols

comment:28 in reply to:  27 Changed 8 years ago by asn

Replying to ioerror:

asn said he'd look into this as a possible issue:
http://sock-raw.org/papers/abusing_network_protocols

It seems like:
http://pidgin.im/pipermail/commits/2011-May/019293.html
saves the day.
Basically, pidgin will use the account proxy even for proxy connections; and if there is no account proxy it uses the global proxy (which the Tor pidgin option thing is).

I also asked in the pidgin dev XMPP room and they confirmed that pidgin uses the account/global proxy options for connecting to other proxies.

comment:29 in reply to:  25 Changed 8 years ago by rransom

Replying to ioerror:

I think that we don't need to write anything new - we simply do not support XMPP related DNS SRV requests at this time.

Let me translate that into user-speak:

tor im browser bundle doesnt work

Users won't know that they need to perform a DNS query by hand. They won't even know what that means. Thus, we need to make Pidgin perform the DNS SRV queries it needs for XMPP through Tor, using DNS-over-TCP.

comment:30 Changed 8 years ago by proper

Is there any progress on this one? Can you/will you fix it? Or can't it be fixed or have you given up on it? There is no news about the Tor Browser IM Bundle for a long time.

When this can't be fixed, see #5498 for my very alternative proposal.

comment:31 Changed 8 years ago by xnyhps

Cc: tor@… added

comment:32 in reply to:  30 ; Changed 8 years ago by ioerror

Replying to proper:

Is there any progress on this one? Can you/will you fix it? Or can't it be fixed or have you given up on it? There is no news about the Tor Browser IM Bundle for a long time.

It's just a matter of testing the build that Erinn produced - I've been too busy to do it because it requires a copy of Windows. I'll try to get a Windows VM up and test the basic DNS leaking issues with xmpp in the next week.

When this can't be fixed, see #5498 for my very alternative proposal.

These issues are orthogonal, I think.

comment:33 Changed 8 years ago by rubin110

Cc: rubin@… added

comment:34 Changed 8 years ago by minifig404

Cc: proegssilb@… added

If you guys think it has a strong chance of working, I'd be willing to help with testing on a live/used-daily system. I'm a busy CS student, so not sure how much help I can be with debugging, but it might be better than nothing.

comment:35 Changed 8 years ago by rubin110

I've been spending the past week getting a couple test environments setup for this bug (but mostly to also hack/test on more tor related bugs). Going to knock on it today, but more help the better. :)

comment:36 in reply to:  32 Changed 7 years ago by rubin110

Replying to ioerror:

It's just a matter of testing the build that Erinn produced - I've been too busy to do it because it requires a copy of Windows. I'll try to get a Windows VM up and test the basic DNS leaking issues with xmpp in the next week.

What build are you speaking of? Pidgin or Tor? Or should I attempt to build this from scratch for Windows with the linked to patches?

Currently running the tor-browser-2.2.35-8_en-US bundle with Pidgin 2.10.3 (libpurple 2.10.3) on Windows 7, with "Server" populated in the Advanced tab, seeing DNS leaks.

comment:37 Changed 7 years ago by rubin110

So after scratching my brain for a bit, actually rereading much of this thread, and a bit of retesting...

The new build people have been speaking of is Pidgin, the change is a new item in the proxy type menu called "Tor/Privacy (SOCKS5)" which seems to push DNS through Tor.

Via the XMPP connection protocol I'm able to make successful connections to CCC's jabber server and talk.google.com without any DNS leakage.

The "GTalk" connection protocol uses gmail.com as the server, which seems to choke on making SRV look ups. This is also the case if gmail.com is used as the server in the XMPP connection protocol. Basically it fails to connect but with no DNS leakage.

I don't know if whoever packages this could simply rebuild Pidgin with talk.google.com in the server spot by default for GTalk instead of gmail.com. Additionally I have the feeling if the exit node is terminating out of Germany, gmail.com wont actually work, but I could be wrong.

Also tested under the new Tor/Privacy proxy type was chatting over AIM, which worked without issue. Is Tor planning to support any other IM protocols? If so I can quickly test the rest of those out too.

I'm going to poke file transfers and other forms of possibly leakage in a bit, with a primary focus on XMPP through CCC and talk.google.com.

comment:38 in reply to:  37 Changed 7 years ago by ioerror

Replying to rubin110:

So after scratching my brain for a bit, actually rereading much of this thread, and a bit of retesting...

The new build people have been speaking of is Pidgin, the change is a new item in the proxy type menu called "Tor/Privacy (SOCKS5)" which seems to push DNS through Tor.

Right - exactly so.

Via the XMPP connection protocol I'm able to make successful connections to CCC's jabber server and talk.google.com without any DNS leakage.

Great. In theory - this should be be the default mode.

The "GTalk" connection protocol uses gmail.com as the server, which seems to choke on making SRV look ups. This is also the case if gmail.com is used as the server in the XMPP connection protocol. Basically it fails to connect but with no DNS leakage.

Yes, that is expected and this confirms the goal of the patch.

I don't know if whoever packages this could simply rebuild Pidgin with talk.google.com in the server spot by default for GTalk instead of gmail.com. Additionally I have the feeling if the exit node is terminating out of Germany, gmail.com wont actually work, but I could be wrong.

In theory, yes - though in practice, I think we need to set the connect server to talk.google.com and the main server to gmail.com - eg you@… but connecting through talk.google.com over Tor.

Also tested under the new Tor/Privacy proxy type was chatting over AIM, which worked without issue. Is Tor planning to support any other IM protocols? If so I can quickly test the rest of those out too.

If they are confirmed to not leak, yes. There are subtickets - if you do the review, they can be added into the bundle. At first glance, I think that AIM is fine except that their data retention policy is HORRIBLE as far as chatting goes.

I'm going to poke file transfers and other forms of possibly leakage in a bit, with a primary focus on XMPP through CCC and talk.google.com.

Sounds good. XMPP is first, feel free to do others after that...

comment:39 Changed 7 years ago by erinn

Rubin,

I re-read this thread with confusion because I knew I made a Tor IM bundle pre-built with pidgin and didn't see it anywhere here (and this is the build ioerror was referring to). But there is actually a whole other bug! Please see #2918 -- it has the test IM bundle with IRC, Jabber, and AIM enabled (if I remember correctly). That's the thing you're supposed to test, sorry you had to go through all that trouble up there.

I can't figure out how to link to a specific comment, but it's number 27 and the link to the (very outdated) bundle is here:
http://erinn.org/~e/tor-im-browser-2.2.33-3-UNOFFICIAL_en-US.exe

comment:40 Changed 7 years ago by rubin110

With Erinn's Tor IM bundle I'm able to make complete connections to CCC's jabber server, no problem, no leakage. This is with all of the proxy settings preconfigured out of the box.

Connecting to a gmail account fails as expected with the default settings due to SRV look up choke.

What's interesting now is that connecting to talk.google.com for a username@… account, the server returns with an SSL cert for gmail.com.

Accept certificate for talk.google.com?
The certificate for talk.google.com could not be validated.
The certificate claims to be from "gmail.com" instead. This could mean that you are not connecting to the service you believe you are.

The user is proivded buttons to "View Certificate...", accept or reject. If you view...

Common name: gmail.com
Fingerprint (SHA1): 78:42:95:7e:7a:28:28:c1:88:b9:8d:5a:2a:d4:a5:78:3e:8a:21:06
Activation date: Thu Jan 19 17:05:56 2012
Expiration date: Sat Jan 19 17:15:56 2013

I'm about 99% sure I didn't simply click through any sort of SSL warning 2 weeks ago when I tested this last. Additionally Pidgin running for me personally (configured to poke talk.google.com) under Debian Sid hasn't thrown up any SSL cert errors. Does anyone else see this?

comment:41 Changed 7 years ago by rubin110

Mostly related to @gmail.com accounts via XMPP...

After not being able to sleep over this I've completed a little bit more research and poked some fine folks on IRC regarding what the default behaviors here should be.

There are three basic fields that Pidgin presents to the user for the XMPP protocol, two of which must be populated to make any connection.

Username
Domain
Connect server (in most cases optional)

I'll referring to them in this comment with the first letter capitalized for each field. The Domain is also called the jid server.

Example 1: @gmail.com with SRV look up

Let's say Jane has a gmail account, her email address is jane@…, which Google refers to as also her Google Talk account name. From that Jane can populate the fields as such...

Username: jane
Domain: gmail.com
Connect server: [blank]

Pidgin takes the content in the Domain field, and attempts an SRV look up to see what server it should talk to. In the case of Tor this would fail, which at that point I'm pretty sure pidgin gives up and attempts to use the A record for that domain (such as the case with jabber.ccc.de). Once Pidgin has an IP address it should talk to, it attempts a STARTTLS handshake, makes sure the domain referred to in the cert matches up with the Domain field in Pidgin's account settings we listed above (gmail.com), checks to make sure the cert is valid, and progresses along completing the XMPP connection.

Now again, this would all fail through Tor due to the SRV request if Jane was using gmail.com as her Domain.

Example 2: @example.com hosted through Google Apps for Domains without SRV lookup

Jane also owns example.com, and has setup a Google Apps for Domains account with Google, turning on GTalk for her domain. Her email address is jane@…. If she wanted to use a 3rd party client to connect to the XMPP service, Google recommends that she populates the fields in Pidgin as such...

Username: jane
Domain: example.com
Connect server: talk.google.com

If the Connect server is populated Pidgin ignores making an SRV look up on the Domain address all together and connects directly to the Connect server address, which sort of solves that previous issue with Tor. Pidgin tells talk.google.com that the jid server (Domain) it wants to discuss is example.com. talk.google.com then sends back a an SSL cert for talk.google.com.

At this point we hit our first discrepancy. What I was informed in #jabber on freenode should happen is that the XMPP client should compare that certificate to whatever is populated in the Domain field, namely the jid server. This is mainly to combat a man in the middle attack sending out bogus addresses when an SRV response happens. If the Connect server field is populated too, the XMPP client should still compare the cert to the Domain field. Additionally the server should only send an SSL cert specified for the Domain (jid server) and not whatever host address the server is running off of.

This is discussed within the Pidgin project apparently a number of times, their take on it is slightly different. If no Connect server is provided, the cert should of course be verified against the Domain. But if a Connect server is provide, the cert should be verified against that. There was discussion about using the Domain as fall back, if verification against the Connect server failed, but I can't find any references of that being implemented. So Pidgin is expecting to see a cert made out for the Connect server host address and not the Domain (jid server).

So in Jane's case, Pidgin starts a handshake with talk.google.com (after sending some Jabber XML stating what jid server (Domain) she was talking about), a cert is handed down with talk.google.com in the commonName field, Pidgin verifies this against the Connect server field, it's a match, Jane continues on with sign-in and wins. Additionally if she's using Tor, all this works since there's no SRV look up. Jane double wins.

Regardless of what the Domain (jid server) is, Google will always respond back with talk.google.com. Again from my understanding of the XMPP spec as explained to me by #jabber, this is incorrect behavior and the server should actually provide an SSL cert for the address listed in Domain, specifically the jid server. Wile this isn't correct, Pidgin is fine with it since it actually doesn't care about the Domain if the Connect server field is populated, which also isn't correct. Two wrongs make a right?

Example 3: @gmail.com without SRV look up

Jane lied, she doesn't own example.com. Her Google account is jane@…, and she wants to use Tor. She configures Pidgin as such to get around the SRV look up limitation...

Username: jane
Domain: gmail.com
Connect server: talk.google.com

So Pidgin should now connect to talk.google.com, tell the server that the jid server (Domain) it's wanting to talk about is gmail.com, and expect a nice cert. The second discrepancy here is on Google. With every other hosted domain they'll provide an SSL cert with talk.google.com in the commonName, regardless of what the jid server (Domain) specified is. Sadly that's not the case if the Domain field is populated with gmail.com, talk.google.com will respond back with a cert for gmail.com. While that's actually the expected behavior (as stated by #jabber), Pidgin isn't expecting this. gmail.com from the cert and talk.google.com from the Connect server field are a mismatch, Pidgin doesn't bother to fall back to the Domain field, Pidgin throws an error up as stated in my previous bug. Jane turns into a scared child who is frightened by phrases like "could not be validated" and decides today isn't the day she uses the internet.

So where to go from here. First off the only way Pidgin can make a connection to Google's XMPP service is through the talk.google.com server, so when Gtalk is selected as a protocol we would need to auto populate the Connect to field with talk.google.com.

For the SSL issue, I'm doubtful Google will change anything on their end. I think after I get done writing this comment, I'll see about starting a bug on Pidgin's trac asking if it's possibly to implement the fall back to Domain option for cert verification that was discussed in the first bug I'm linking to at the bottom of this comment.

Other than that, no leakage, I'll see about testing out a little bit of AIM and IRC tonight.

http://developer.pidgin.im/ticket/6516
http://developer.pidgin.im/ticket/14614
http://developer.pidgin.im/ticket/14774

comment:42 Changed 7 years ago by rubin110

Fallback to jid server fails when hitting an SSL cert mismatch with connect server address
http://developer.pidgin.im/ticket/15111

comment:43 Changed 7 years ago by xnyhps

Just wanted to mention that there is a 4th case for GTalk: old-style SSL on port 5223 (seems to also work over 443). When connecting there, Google always responds with a certificate for talk.google.com, even when it later turns out the user was using a GMail-account. So this would currently work in both the GAFYD case and the GMail case, and can be done if you want to avoid patching Pidgin.

(Old-style SSL also means the domain a user wishes to use is not transmitted in plain text, contrary to the case of STARTTLS, but I'm not sure if this is really something for you to be concerned about.)

comment:44 Changed 7 years ago by arma

Priority: criticalnormal

comment:45 Changed 5 years ago by erinn

Keywords: needs-triage added

comment:46 Changed 5 years ago by erinn

Component: Tor bundles/installationTor Messenger

Can we close this or is it still relevant?

comment:47 Changed 5 years ago by intrigeri

Cc: intrigeri added; amnesia@… removed

comment:48 Changed 5 years ago by arlolra

Resolution: invalid
Status: assignedclosed

Closing, considering TorMessenger won't be based on Pidgin.

comment:49 Changed 12 months ago by traumschule

Parent ID: #2918
Severity: Blocker

Just to clarify: the ticket has been closed as invalid because the intention to use pidgin for TorMessenger did go (#2918), just as the latter itself. For alternatives see https://blog.torproject.org/tor-heart-onion-messaging

Unfortunately the ticket description still makes a valid point. You can verify this with torsocks -d. The DNS requests are blocked and pidgin is waiting for reply hanging forever with

Waiting for connection.

The torsocks log shows:

DEBUG torsocks[30140]: IPv4/v6 non TCP socket denied. Tor network can't handle it. (in tsocks_socket() at socket.c:69)
DEBUG torsocks[30140]: [conect] Connection is not IPv4/v6. Ignoring. (in tsocks_validate_socket() at connect.c:63)

doc/TorifyHOWTO/InstantMessaging#Libpurple-basedclients rightfully states:

Warning: Libpurple has been proven critically flawed in recent years. While problems do continually come up related to that and most times they are subsequently patched, the long-term vulnerability of the platform is inevitable and therefore it is recommended against using any of the software listed below.

(leaving it closed though because there is still no reason to audit)

comment:50 Changed 12 months ago by traumschule

<+sukhe> hello. yes, I think it's fine to close the tickets. thanks for doing what we should done earlier :)

sad but true:
https://blog.torproject.org/sunsetting-tor-messenger

luckily there are alternatives:
https://blog.torproject.org/tor-heart-onion-messaging

.. and maybe someday

Note: See TracTickets for help on using tickets.