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

[Tor Bug Tracker & Wiki]

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

Comment (by pospeselr):

 Wow, this is janky.  Definitely agree with cypherpunks that eventually
 firefox should probably handle file-dialogs internally the same way
 everywhere.  Otherwise we're just waiting for GTK/KDE/MacOS/Windows devs
 to break us.

 === Code Fixes:

 ::GetDlgItemText truncates the requested string based on the nMaxCount
 provided.  Given that scheme part of the URI (http, https, ftp, etc) is
 going to be short, does it make sense to have a smaller buffer?

 messageBuffer ought to just be an HLOCAL (which is just a typedef'd HANDLE
 which itself is a typede'd void*) rather than LPTSTR.  The memory
 allocated by ::FormatMessageW is done so using ::LocalAlloc.  You also
 need to add a ::LocalFree(messageBuffer) call after we're finished with
 messageBuffer.

 === Approach in General:

 Checking the URI string for ':^^/^^/' is not sufficient.  Playing around
 in a Win10 VM, you can access SMB shares via strings like:

 * {{{ \\Hostname\Path\To\File.txt }}}
 * {{{ \\192.168.50.123\Path\To\File.txt }}}

 However, this is sort of irrelevant because (on Win10 at least) the file
 explorer does DNS and LLMNR (for local shares) queries AS YOU TYPE for
 SMB.  So for instance, if you have an SMB share of the form
 {{{\\other\shared}}} as soon as you type that '\' before shared an LLMNR
 request is sent out.  Same story if you query {{{\\wwww.cnn.com\shared}}}
 a DNS request gets sent out.  The requests will also be triggered on
 paste.

 This auto-lookup does not occur with https/http/ftp URIs, only windows SMB
 strings starting with ^^\^^\ .

 After a fair amount of digging today it doesn't look like there's an easy
 way to fix this.  I'd hoped a fix would be as easy as detouring the
 relevant DNS API, but the DNS request doesn't appear to be coming from the
 process which opens the file dialog.  The URL string does get passed
 through RPC APIs several times (which makes me think some service is doing
 the request).

 We might be able to detour whichever root offending function is causing
 the DNS request to happen but that will require more investigation, and
 would be inherently fragile and would need to be tested on every Windows
 SKU.

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