Opened 2 years ago

Last modified 2 weeks ago

#15161 reopened defect

CTCP fingerprinting

Reported by: cypherpunks Owned by: sukhbir
Priority: Immediate Milestone:
Component: Applications/Tor Messenger Version:
Severity: Normal Keywords:
Cc: gk Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

tor-messenger should beware of irc ctcp fingerprinting.

maybe it should not reply, or reply fake data for TIME and VERSION.

06:16 [ctcp(testtm)] CLIENTINFO
06:16 CTCP CLIENTINFO reply from testtm: DCC ACTION ERRMSG CLIENTINFO PING TIME VERSION
06:16 [ctcp(testtm)] PING
06:16 CTCP PING reply from testtm:
06:16 [ctcp(testtm)] TIME
06:16 CTCP TIME reply from testtm: :Thu Mar 05 2015 06:16:57 GMT+0000 (UTC)
06:16 [ctcp(testtm)] VERSION
06:17 CTCP VERSION reply from testtm: Instantbird 1.6a1pre

Child Tickets

Change History (17)

comment:1 Changed 2 years ago by sukhbir

  • Owner set to sukhbir
  • Status changed from new to accepted

Thanks for reporting this. Someone in IRC pointed this out and we were discussing on how to handle this. More tickets related to this shortly.

comment:2 Changed 2 years ago by sukhbir

  • Parent ID set to #15162

comment:3 Changed 2 years ago by arlolra

This is coming from,
https://github.com/mozilla/releases-comm-central/blob/master/chat/protocols/irc/ircCTCP.jsm#L227

let version = Services.appinfo.name + " " + Services.appinfo.version;

Need to patch the application info when building.

comment:4 follow-up: Changed 2 years ago by sukhbir

Another related is leak is the username, which is set by default to the brand name (Instantbird).

~Instantbi@tor-irc.dnsbl.oftc.net] requested CTCP TIME from

comment:5 Changed 2 years ago by sukhbir

The CTCP time leak has been fixed where we are replacing the local time with the time in UTC so that no timezone information is leaked.

For the user agent which is reflected in CTCP version (among other places) we are using Instantbird 1.5 which is the user agent of Instantbird stable.

comment:6 in reply to: ↑ 4 Changed 2 years ago by sukhbir

Replying to sukhbir:

Another related is leak is the username, which is set by default to the brand name (Instantbird).

~Instantbi@tor-irc.dnsbl.oftc.net] requested CTCP TIME from

Since we are no longer trying to pretend that we are not Instantbird, we are not changing this.

comment:7 Changed 2 years ago by sukhbir

And we are completely disabling the CTCP ping command.

comment:8 Changed 2 years ago by sukhbir

  • Resolution set to fixed
  • Status changed from accepted to closed

Closing this ticket for now since we have handled all issues. Please feel free to reopen if required.

comment:9 follow-up: Changed 2 years ago by arlolra

  • Cc gk added
  • Resolution fixed deleted
  • Status changed from closed to reopened

From gk's audit,

While looking over ctcp-time.patch I got reminded by the problem that Date methods may leak locale and or platform version information ("The format of the return value may vary according to the platform" (see: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toUTCString). It might be worth verifiying that this is not a problem for Tor Messenger (Tor Browser had/has #5926/#13019 and #15473 for this issue).

comment:10 Changed 2 years ago by sukhbir

  • Parent ID changed from #15162 to #14161

comment:11 in reply to: ↑ 9 Changed 2 years ago by sukhbir

  • Resolution set to fixed
  • Status changed from reopened to closed

Replying to arlolra:

From gk's audit,

While looking over ctcp-time.patch I got reminded by the problem that Date methods may leak locale and or platform version information ("The format of the return value may vary according to the platform" (see: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toUTCString). It might be worth verifiying that this is not a problem for Tor Messenger (Tor Browser had/has #5926/#13019 and #15473 for this issue).

I have confirmed both with CTCP TIME and by running new Date().toUTCString() (which is what CTCP TIME calls) on all platforms and there is no difference in the result so we are not leaking anything here.

comment:12 Changed 2 years ago by arlolra

  • Resolution fixed deleted
  • Status changed from closed to reopened

I'm not entirely convinced. Is there a TB patch we can look at?

Did you try on a different language OS as in https://trac.torproject.org/projects/tor/ticket/5926#comment:7

Are there other uses of these date function in the codebase?

comment:14 Changed 2 years ago by sukhbir

  • Resolution set to fixed
  • Status changed from reopened to closed

I have confirmed on systems with non-English locale that `CTCP TIME` returns the date without leaking the locale.

Additionally, we are using the Tor Browser Bundle patch from #13019 to set the JS locale to English.

comment:15 follow-up: Changed 7 months ago by cypherpunks

  • Parent ID #14161 deleted
  • Resolution fixed deleted
  • Severity set to Normal
  • Status changed from closed to reopened

Why not to remove ctcp responses completely (but act on them to indicating that someone is probing the user)? In fact it is not needed for operation. I was very surprised that it discloses local time which can easily be used for deanonimization using clock drift and/or giving unique time to each client from public NTP servers.

Last edited 7 months ago by cypherpunks (previous) (diff)

comment:16 Changed 7 months ago by cypherpunks

  • Priority changed from Medium to Immediate

comment:17 in reply to: ↑ 15 Changed 2 weeks ago by cypherpunks

Replying to cypherpunks:

Why not to remove ctcp responses completely (but act on them to indicating that someone is probing the user)? In fact it is not needed for operation. I was very surprised that it discloses local time which can easily be used for deanonimization using clock drift and/or giving unique time to each client from public NTP servers.

Removing CTCP support completely is a bad idea. Many IRC servers rely on VERSION support in order to expose features to the user. Additionally, some channels may have bots that CTCP you when you join, and kick you if your client does not respond. If there is no CTCP VERSION support, this client would be additionally breaking the agreements of several large public IRC servers, like Rizon.

VERSION can be implemented without jeopardizing anonymity. PING is another important CTCP request which I don't believe is unsafe, unless knowing a client's approximate lag is problematic. The timestamp field does not need to be based on the system's local time, and can even start with a random integer. The SOURCE request could link to Tor Project's webpage, providing some free advertising. ACTION also poses no safety issues, and is an important part of the IRC experience. USERINFO and CLIENTINFO do not provide any information that's not already available via WHOIS, though they're not strictly necessary. DCC has many anonymity issues, and is interfered with by Tor itself. FINGER is rarely used anymore and is not safe to implement anyway.

Some common implementation security issues can be seen in http://www.irchelp.org/protocol/ctcpspec.html. I have actually seen Pidgin respond to a request while infoleaking the current conversation being discussed in the NOTICE reply.

Please don't remove all CTCP support. Just selectively respond to important and safe requests.

Note: See TracTickets for help on using tickets.