[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #18101 [Applications/Tor Browser]: IP leak from Windows UI dialog with URI
#18101: IP leak from Windows UI dialog with URI
-------------------------------------------------+-------------------------
Reporter: uileak | Owner:
| arthuredelstein
Type: defect | Status:
| needs_revision
Priority: Very High | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Major | Resolution:
Keywords: tbb-disk-leak, tbb-proxy-bypass, | Actual Points:
TorBrowserTeam201711 |
Parent ID: | Points:
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Comment (by arthuredelstein):
Replying to [comment:54 gk]:
> With the patch for Windows I still see DNS leaks. Here is what I did:
I was able to reproduce this on Windows 7, but not on Windows 8 Server or
Windows 10.
To attempt to fix this on Windows 7, I tried using both IFileDialog and
GetOpenFileName. Both show the same modern file dialog. It's possible to
hook some UI events in both, using IFileDialogEvents and
OPENFILENAME.lpfnHook respectively. But, unfortunately, there is no event
that occurs after the user clicks the "Open" button (or presses enter),
and before the DNS leak occurs, that could allow us to cancel the event
and prevent the leak.
As an experiment, I tried using the Windows Firewall to block internet
connections from firefox.exe. While browsing the web is blocked as
expected, the file dialog still causes DNS leaks! So it seems the leak may
be happening outside the browser process.
I also looked into `IFileDialogCustomize::RemoveControlItem`, but as far
as I could tell, this function only applies to custom control items added
to the dialog by the application; default control items cannot be removed.
So, finally, I did find one method that works. It involves:
1. Use GetOpenFileName
2. Exclude `OFN_EXPLORER` from OPENFileName.Flags;
3. Use an "Old-Style" hook function
The result is an "old-style" file dialog. No DNS leaks occur when the user
enters a remote URL. And the dialog says "The file name is not valid."
The main drawback is the dialog is the design from Windows 3.1 (no joke).
Here it is:
[[Image(ye_old_file_dialogue.png)]]
I guess this dialog is so primitive it doesn't know how to process URLs.
So we could force Windows 7 and earlier to use this dialog. It's a rather
stark usability/privacy tradeoff. What do people think? I'll post a patch
if people think this UI is acceptable. I'm also very open to other
suggestions for fixing this.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18101#comment:62>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs