[tor-bugs] #18101 [Applications/Tor Browser]: IP leak from Windows/macOS UI dialog with URI

[Tor Bug Tracker & Wiki]

#18101: IP leak from Windows/macOS UI dialog with URI
-------------------------------------------------+-------------------------
 Reporter:  uileak                               |          Owner:
                                                 |  arthuredelstein
     Type:  defect                               |         Status:
                                                 |  needs_review
 Priority:  Medium                               |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Major                                |     Resolution:
 Keywords:  tbb-disk-leak, tbb-proxy-bypass,     |  Actual Points:
  TorBrowserTeam201906R                          |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by gk):

 Replying to [comment:88 mcs]:
 > Replying to [comment:84 gk]:
 > > Okay, let's get this on our radar again to squash this bug finally.
 `bug_18101` (https://gitweb.torproject.org/user/gk/tor-
 browser.git/commit/?h=bug_18101) in my `tor-browser` repo has the patch
 ideas Arthur and a cypherpunk/ericlaw came up with for (re)-review.
 > >
 > > mcs/brade: could you take the macOS part?
 >
 > It is unclear how to produce an IP address leak on macOS 10.9 or newer.
 As teor mentioned in comment:9, Apple seems to have removed features years
 ago that allowed URLs to be entered in the file open and file save panels.
 At least, Kathy and I do not know how to do so.

 If we are sure those features got removed in 10.9 (and later) and/or you
 don't see any leaks in Wireshark on 10.9 (and later), then let's declare
 victory and just omit the patch Arthur wrote?

 > Looking at the patch, it is also unclear what effect the `[NSOpenPanel
 setCanDownloadUbiquitousContents:NO]` call has (the documentation does
 makes it sound like setting it to `NO` is a good idea).
 >
 > In any case, that API requires macOS 10.10 or newer (as documented here
 https://developer.apple.com/documentation/appkit/nsopenpanel/1533418-candownloadubiquitouscontents?language=objc).
 To make sure, we tested a patched Tor Browser on a macOS 10.9.5 system,
 and indeed an exception was thrown which prevents the file open dialog
 from opening:
 >  ... firefox[...] -[NSOpenPanel setCanDownloadUbiquitousContents:]:
 unrecognized selector sent to instance 0x10bbc5270
 >  ... firefox[...] Mozilla has caught an Obj-C exception
 [NSInvalidArgumentException: -[NSOpenPanel
 setCanDownloadUbiquitousContents:]: unrecognized selector sent to instance
 0x10bbc5270]
 >
 > We would need to add a runtime check to make sure that API is available.
 If we do use `setCanDownloadUbiquitousContents`, we may also want to add a
 similar call inside `nsFilePicker::GetLocalFolder()` (also in
 `widget/cocoa/nsFilePicker.mm`).

 Fair enough. But let's actually double-check whether we still need to do
 that patching (Arthur at least seemed under the impression there would be
 work we needed to do given that `setCanDownloadUbiquitousContents` was not
 set to `NO`).

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18101#comment:89>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online