Opened 22 months ago

Last modified 4 days ago

#18101 needs_revision defect

IP leak from Windows UI dialog with URI

Reported by: uileak Owned by: arthuredelstein
Priority: Very High Milestone:
Component: Applications/Tor Browser Version:
Severity: Major Keywords: tbb-disk-leak, tbb-proxy-bypass, TorBrowserTeam201711
Cc: gk, mcs, brade, pospeselr Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

It is possible for the client IP to leak from the browser and onto the network via the Windows API when prompted with Windows dialog box to select files.

Not entirely sure if this is a bug, but should at least be documented.

Steps to reproduce:

  1. Visit a website that provides an upload box.
  2. Instead of selecting a file, paste a URI as a file name.
  3. The IP is leaked.

This may potentially work with Ctrl+O (Open File) and Ctrl+S (Save Page As).

Tested on Windows 7 and verified with Wireshark.

Child Tickets

Attachments (1)

ye_old_file_dialogue.png (22.5 KB) - added by arthuredelstein 2 weeks ago.

Download all attachments as: .zip

Change History (74)

comment:1 Changed 22 months ago by uileak

Priority: MediumHigh

comment:2 Changed 22 months ago by cypherpunks

Keywords: ip-leak added; IP leak removed
Version: Tor: unspecified

comment:3 Changed 22 months ago by cypherpunks

Keywords: tbb-proxy-bypass added

comment:4 Changed 22 months ago by cypherpunks

Seems like it is undocumented (?) but well known feature for Windows Vista+

Possible workarounds (need to check if they actually works and useful):

  1. To use file picker's code for old Windows
  2. To remove "File name" edit box by IFileDialogCustomize::RemoveControlItem
  3. To filter user input on by OnFileOk (nsFilePicker::OnFileOk)
Version 0, edited 22 months ago by cypherpunks (next)

comment:5 Changed 22 months ago by gk

Cc: gk added
Keywords: TorBrowserTeam201601 added
Severity: NormalMajor

comment:6 Changed 22 months ago by cypherpunks

More info about another OS/managers:

Gnome Open File dialog used in Ubuntu doesn't support this feature, however, the File Open dialog used in KDE is able to open HTTP URLs. I'm not sure what is the situation with support in other other desktop environments that run on Ubuntu.
Just tested this in KDE - indeed, it works in KDE just fine. Nice, I didn't know about this feature.

comment:7 Changed 22 months ago by cypherpunks

Gtk disallows URLs by default.

comment:8 Changed 22 months ago by cypherpunks

To use ​file picker's code for old Windows

Tested those deprecated API, it works but useless. It launches download anyway.

comment:9 Changed 22 months ago by teor

OS X used to allow URLs in some contexts, but now (10.11) appears to disallow URLs in open dialogs.

comment:10 Changed 22 months ago by cypherpunks

feature for Windows Vista+

Since Windows XP

comment:11 Changed 22 months ago by cypherpunks

In Soviet Mozilla file uploads you.

comment:12 Changed 22 months ago by cypherpunks

Reverting this should be about fix this bug?

comment:13 Changed 22 months ago by cypherpunks

Thus API involved leaks could be fixed in general by setting proxy per process at start. (by InternetSetOption from urlmon.dll with INTERNET_OPTION_PROXY option with defined INTERNET_PROXY_INFO structure, to /dev/null)

comment:14 Changed 22 months ago by cypherpunks

Thus API involved leaks could be fixed in general by setting proxy per process at start.

This approach if alone still leaves disk traces (it writes some information to IE's cache). Fix shouldn't leave any leaks. Proxy option could be helpful still for some unknown yet API-involved leaks, as proactive protection (tbb-disk-leak < tbb-proxy-bypass)

comment:15 Changed 22 months ago by gk

Keywords: TorBrowserTeam201602 added; TorBrowserTeam201601 removed

Putting stuff on the radar for February.

comment:16 Changed 22 months ago by gk

Keywords: GeorgKoppen201602 added

comment:17 Changed 21 months ago by gk

Keywords: GeorgKoppen201603 added; GeorgKoppen201602 removed

comment:18 Changed 21 months ago by gk

Keywords: TorBrowserTeam201603 added; TorBrowserTeam201602 removed

comment:19 Changed 20 months ago by gk

Keywords: GeorgKoppen201604 added; GeorgKoppen201603 removed

comment:20 Changed 20 months ago by gk

Keywords: TorBrowserTeam201604 added; TorBrowserTeam201603 removed

comment:21 Changed 19 months ago by gk

Keywords: TorBrowserTeam201605 added; TorBrowserTeam201604 removed

Moving tickets

comment:22 Changed 19 months ago by gk

Keywords: GeorgKoppen201605 added; GeorgKoppen201604 removed

Moving things for me to May.

comment:23 Changed 18 months ago by gk

Keywords: GeorgKoppen201606 added; GeorgKoppen201605 removed

comment:24 Changed 18 months ago by gk

Keywords: TorBrowserTeam201606 added; TorBrowserTeam201605 removed

comment:25 Changed 18 months ago by gk

Owner: changed from tbb-team to gk
Status: newassigned

comment:26 Changed 17 months ago by gk

Keywords: GeorgKoppen201607 added; GeorgKoppen201606 removed

Moving my tickets

comment:27 Changed 17 months ago by gk

Keywords: TorBrowserTeam201607 added; TorBrowserTeam201606 removed

comment:28 Changed 16 months ago by gk

Keywords: TorBrowserTeam201608 added; TorBrowserTeam201607 removed

Moving items to August 2016.

comment:29 Changed 16 months ago by gk

Keywords: GeorgKoppen201608 added; GeorgKoppen201607 removed

Moving my tickets as well.

comment:30 Changed 15 months ago by gk

Keywords: GeorgKoppen201609 added; GeorgKoppen201608 removed

Moving my tickets

comment:31 Changed 15 months ago by gk

Keywords: TorBrowserTeam201609 added; TorBrowserTeam201608 removed

Tickets for September.

comment:32 Changed 14 months ago by gk

Keywords: GeorgKoppen201610 added; GeorgKoppen201609 removed

Moving my tickets

comment:33 Changed 14 months ago by gk

Keywords: TorBrowserTeam201610 added; TorBrowserTeam201609 removed

Moving tickets to October.

comment:34 Changed 13 months ago by gk

Keywords: GeorgKoppen201611 added; GeorgKoppen201610 removed

Moving my tickets to November.

comment:35 Changed 13 months ago by gk

Keywords: TorBrowserTeam201611 added; TorBrowserTeam201610 removed

Moving tickets over to November.

comment:36 Changed 12 months ago by gk

Keywords: GeorgKoppen201612 added; GeorgKoppen201611 removed

Moving my tickets

comment:37 Changed 11 months ago by gk

Keywords: GeorgKoppen201701 added; GeorgKoppen201612 removed

comment:38 Changed 11 months ago by gk

Keywords: TorBrowserTeam201701 added; TorBrowserTeam201611 removed

comment:39 Changed 10 months ago by gk

Keywords: TorBrowserTeam201702 added; TorBrowserTeam201701 removed

Moving our tickets to Feb 2017.

comment:40 Changed 10 months ago by gk

Keywords: GeorgKoppen201702 added; GeorgKoppen201701 removed

Moving my tickets as well

comment:41 Changed 9 months ago by elisebenine

could it be something related to browser's File API? noticed the same on http://internetvergelijken.nl/ today.

comment:42 Changed 4 months ago by gk

Keywords: TorBrowserTeam201708 GeorgKoppen201708 added; TorBrowserTeam201702 GeorgKoppen201702 removed
Priority: HighVery High

comment:43 Changed 4 months ago by arthuredelstein

Keywords: GeorgKoppen201708 removed
Owner: changed from gk to arthuredelstein

comment:45 Changed 3 months ago by arthuredelstein

Here's a patch that blocks the use of remote URLs in the open file dialog on Windows:

https://github.com/arthuredelstein/tor-browser/commit/18101

(It essentially reverses the change in https://bugzilla.mozilla.org/show_bug.cgi?id=711654.)

comment:46 Changed 3 months ago by arthuredelstein

Keywords: TorBrowserTeam201708R added; TorBrowserTeam201708 removed
Status: assignedneeds_review

comment:47 Changed 3 months ago by arthuredelstein

I should mention, in the patch in comment:46, I use perfmon /res to confirm that no network requests were made. Without the patch, in unpatched Tor Browser, I see a network request corresponding to the remote URL entered in the open dialog box.

comment:48 Changed 3 months ago by gk

Status: needs_reviewneeds_information

Arthur: What do we want to do for XP (see comment:10)? And could you verify that other Tor Browser platforms are unaffected? comment:7 seems to point this out for Linux. See comment:9 for macOS.

comment:49 in reply to:  48 ; Changed 3 months ago by arthuredelstein

Status: needs_informationneeds_review

Replying to gk:

Answering questions in reverse order:

And could you verify that other Tor Browser platforms are unaffected? comment:7 seems to point this out for Linux. See comment:9 for macOS.

Here's a patch that covers all platforms:
https://github.com/arthuredelstein/tor-browser/commit/18101+2

Unfortunately, I haven't yet been able to test these on old Linux and macOS platforms. The current platforms on desktops I tested (XFCE, KDE, macOS) do not show a text box in the Open Dialog. Once I have builds ready, I will post them on this ticket so that people can test on old Mac/Linux platforms if they have them.

Arthur: What do we want to do for XP (see comment:10)?

I am inclined to treat this problem as wontfix, because XP is deprecated by Microsoft and is expected to be deprecated in September by Mozilla as well. I did spend a little time looking into the problem but I don't see a quick solution.

comment:50 in reply to:  49 Changed 3 months ago by teor

Replying to arthuredelstein:

Unfortunately, I haven't yet been able to test these on old Linux and macOS platforms. The current platforms on desktops I tested (XFCE, KDE, macOS) do not show a text box in the Open Dialog

I can find 3 text boxes in the macOS 10.12 Open Dialog:

  • command-shift-G shows the "Go to the folder" dialog, but doesn't seem to allow URLs
  • the share button (square with upward arrow) allows loading arbitrary share extensions, which can access the network, but they require user action
  • the search field queries the local spotlight database, and stores anything typed into it in the find pasteboard and shares it with other apps (#14139)

comment:51 Changed 3 months ago by cypherpunks

Keywords: tbb-disk-leak added; ip-leak removed

Why is so much attention being paid for this NOTABUG? Feature was requested and discussed in https://bugzilla.mozilla.org/show_bug.cgi?id=711654. Pros and cons are well known for years.
Is this ticket about protection for noobs who can't distinguish between shell and browser? If so, shouldn't we make this feature obey TBB's design requirements? Something like "Firefox should handle URLs (instead of system shell)".
What is needed to pass URLs to Firefox, FOS_ALLNONSTORAGEITEMS and
FOS_SUPPORTSTREAMABLEITEMS (with FOS_FORCEFILESYSTEM removed), from https://msdn.microsoft.com/en-us/library/windows/desktop/dn457282(v=vs.85).aspx?
There is no IP leak or proxy bypass. But there is tbb-disk-leak.

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

comment:52 Changed 3 months ago by gk

Keywords: TorBrowserTeam201709R added; TorBrowserTeam201708R removed

Moving reviews to September.

comment:53 in reply to:  51 Changed 3 months ago by gk

Replying to cypherpunks:

Is this ticket about protection for noobs who can't distinguish between shell and browser? If so, shouldn't we make this feature obey TBB's design requirements? Something like "Firefox should handle URLs (instead of system shell)".

I am fine opening a follow-up ticket for that idea - after we plugged that hole in this ticket.

comment:54 in reply to:  49 ; Changed 3 months ago by gk

Cc: mcs brade added
Status: needs_reviewneeds_revision

Replying to arthuredelstein:

Replying to gk:

Answering questions in reverse order:

And could you verify that other Tor Browser platforms are unaffected? comment:7 seems to point this out for Linux. See comment:9 for macOS.

Here's a patch that covers all platforms:
https://github.com/arthuredelstein/tor-browser/commit/18101+2

Unfortunately, I haven't yet been able to test these on old Linux and macOS platforms. The current platforms on desktops I tested (XFCE, KDE, macOS) do not show a text box in the Open Dialog. Once I have builds ready, I will post them on this ticket so that people can test on old Mac/Linux platforms if they have them.

I built own bundles and this was a PITA to test. I can confirm that the patch for Linux fixes the problem and it looks good to me. After trying to reproduce the problem for quite a while I wrote custom extension code using the example on https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIFilePicker but with modSave (this is important, I could not find a way to reproduce the issue and test the fix with modOpen) and, obviously, nsIFilePicker.filterAllowURLs added to the filters.

Arthur/Mark/Kathy: that might be a way to test the fix on a Mac as well (which I don't have atm).

With the patch for Windows I still see DNS leaks. Here is what I did:

1) Open the patched Tor Browser
2) Go to https://bugs.torproject.org/18101
3) Copy the URL of the Tor logo
4) Open https://bug711654.bmoattachments.org/attachment.cgi?id=582460 in a new tab
5) Start Wireshark
6) Click on the "Browse" button and paste the URL for the Tor log and click on "Open"
7) Wait a while and a DNS query for trac.torproject.org will be in the Wireshark log.

Marking this as needs_revision for this problem. Arthur, let me know whether you can reproduce that. This happens on a Windows 7 machine (in case that matters).

Arthur: What do we want to do for XP (see comment:10)?

I am inclined to treat this problem as wontfix, because XP is deprecated by Microsoft and is expected to be deprecated in September by Mozilla as well. I did spend a little time looking into the problem but I don't see a quick solution.

Well, we certainly would take a patch if someone came up with one. So, let's open a follow-up ticket for that case and set ff59-esr-will-have as keyword once we are done here.

comment:55 Changed 2 months ago by gk

Keywords: TorBrowserTeam201709 added; TorBrowserTeam201709R removed

comment:56 Changed 2 months ago by arthuredelstein

Keywords: TorBrowserTeam201709R added; TorBrowserTeam201709 removed
Status: needs_revisionneeds_review

Thanks for the review, gk. Here's a patch for the Linux fix only, in case we want to put that into the alpha. I'll be testing Mac next by Georg's method and then go back to Windows.

https://github.com/arthuredelstein/tor-browser/commit/18101_linux

Last edited 2 months ago by arthuredelstein (previous) (diff)

comment:57 Changed 2 months ago by gk

Looks still good to me. mcs/brade: Could you have a second look? I'd like to get that one included into the upcoming alphas.

comment:58 in reply to:  57 ; Changed 2 months ago by mcs

Replying to gk:

Looks still good to me. mcs/brade: Could you have a second look? I'd like to get that one included into the upcoming alphas.

r=brade,r=mcs
The patch from comment:56 looks good to us.

comment:59 in reply to:  58 Changed 2 months ago by gk

Keywords: TorBrowserTeam201709 added; TorBrowserTeam201709R removed
Status: needs_reviewneeds_revision

Replying to mcs:

Replying to gk:

Looks still good to me. mcs/brade: Could you have a second look? I'd like to get that one included into the upcoming alphas.

r=brade,r=mcs
The patch from comment:56 looks good to us.

Thanks. Pushed this as commit eb7cb8fe69de4ca08b8aa2ece0faeb7ea6217004 and setting the status back to needs_revision.

comment:60 Changed 7 weeks ago by gk

Keywords: TorBrowserTeam201710 added; TorBrowserTeam201709 removed

Items for October 2017

comment:61 Changed 2 weeks ago by gk

Keywords: TorBrowserTeam201711 added; TorBrowserTeam201710 removed

Moving tickets over to November.

Changed 2 weeks ago by arthuredelstein

Attachment: ye_old_file_dialogue.png added

comment:62 in reply to:  54 Changed 2 weeks ago by arthuredelstein

Replying to 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. Here's the code I used for experimentation: https://gist.github.com/arthuredelstein/eaad2bc94e4836dad831ed7213fbcfe3

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:


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.

Last edited 2 weeks ago by arthuredelstein (previous) (diff)

comment:63 Changed 2 weeks ago by teor

Does a network leak happen when you click "Network" in the old style dialog?
(If it does, at least that's obvious.)

comment:64 in reply to:  63 Changed 2 weeks ago by arthuredelstein

Replying to teor:

Does a network leak happen when you click "Network" in the old style dialog?
(If it does, at least that's obvious.)

Turns out I can remove the Network button in the old style dialog using OFN_NONETWORKBUTTON in OPENFILENAME.Flags. So at least that's one problem solved. :)

comment:65 Changed 13 days ago by mcs

My opinion is that the old dialog is so primitive as to be somewhat alarming. I am not sure what to do about that, except that it would be nice if there was a way to turn off this "feature" OS-wide.

comment:66 Changed 12 days ago by arthuredelstein

I foraged through the Windows API and came up with what I think is a reasonable solution that works with the modern file dialog. Here's the PoC:

https://gist.github.com/arthuredelstein/376e33ce8d4482561593657036db32e8

In this hack, just before the file dialog is created, I set a hook function for window creation. I use some heuristics to identify the File Dialog window, and then I add a second hook that listens for the "Open" command from the user (by button click, enter key, or keyboard shortcut). Before the "Open" command can propagate, I check the text in the dialog's filename text field to see if it looks like a URI, and if so, I clear the text and show an error message to the user explaining that URIs are not allowed. I confirmed this approach prevents any DNS leak.

Instead of clearing the text, it would be better to cancel the "Open" command and leave the text unchanged, but so far I haven't found a way to do that. But I think the usability awkwardness is acceptable, especially given that we explain to the user what has gone wrong.

Anyway, the next step will be to turn this into a patch in Tor Browser.

comment:67 in reply to:  66 Changed 11 days ago by cypherpunks

Replying to arthuredelstein:

I foraged through the Windows API

Have you foraged em'all? :)

In this hack

As it's a hack, could you make it disableable via a pref?

just before the file dialog is created, I set a hook function for window creation. I use some heuristics to identify the File Dialog window, and then I add a second hook that listens for the "Open" command from the user (by button click, enter key, or keyboard shortcut).

and button tap ;)

Before the "Open" command can propagate, I check the text in the dialog's filename text field to see if it looks like a URI, and if so, I clear the text and show an error message to the user explaining that URIs are not allowed.

In the "Open File..." dialog, you can grab that URI and open it, because it's a browser! :)

I confirmed this approach prevents any DNS leak.

What DNS leak? You use OS's feature to load URIs using system proxy settings or you don't.

Instead of clearing the text, it would be better to cancel the "Open" command and leave the text unchanged

and user would say WTF?!

but so far I haven't found a way to do that. But I think the usability awkwardness is acceptable, especially given that we explain to the user what has gone wrong.

Until TBB can handle URIs...

Anyway, the next step will be to turn this into a patch in Tor Browser.

And check the security suites wouldn't mind.

comment:68 in reply to:  66 Changed 8 days ago by arthuredelstein

Keywords: TorBrowserTeam201711R added; TorBrowserTeam201711 removed
Status: needs_revisionneeds_review

Replying to arthuredelstein:

Anyway, the next step will be to turn this into a patch in Tor Browser.

Here's my patch for review. The way it erases the URL from the text box is not ideal, but I still haven't found a better option and I think it is better to have this patch until something better is found. And I don't think I should spend much more time on it if possible. :)

https://github.com/arthuredelstein/tor-browser/commit/18101_windows

comment:69 Changed 8 days ago by gk

Cc: pospeselr added

Thanks for that. I guess Richard could help with reviewing the patch? :)

Arthur: what about verifying the Mac part as mentioned in comment:56?

comment:70 Changed 7 days ago 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.

comment:71 Changed 7 days ago by gk

Keywords: TorBrowserTeam201711 added; TorBrowserTeam201711R removed
Status: needs_reviewneeds_revision

Thanks for the review! Let's talk about SMB in a different bug, though.

comment:72 in reply to:  70 Changed 6 days ago by arthuredelstein

Replying to pospeselr:

Thanks for the review and the very helpful comments.

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.

I think this is a good idea, even if it's fragile. (Of course automated regression tests would help.) I'd like to pursue this instead of my earlier patch.

I managed to obtain a stack trace responsible for the DNS leak when I enter an https:// URL and click the Open button:

06eae9d4 731034ae davclnt!NPGetResourceInformation
06eaea2c 731035a6 MPR!WNetEnumResourceW+0x456
06eaea68 73103558 MPR!WNetEnumResourceW+0x54e
06eaea74 731038c3 MPR!WNetEnumResourceW+0x500
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Windows\syswow64\SHELL32.dll - 
06eaeab4 76b3b8e2 MPR!WNetGetResourceInformationW+0x26
06eaeaf8 76b3b83d SHELL32!SHQueryUserNotificationState+0x56a
06eaeb1c 76e276b2 SHELL32!SHQueryUserNotificationState+0x4c5
06eaef78 76e280c9 SHELL32!StgMakeUniqueName+0x78d0a
06eaf50c 76d0d2d1 SHELL32!StgMakeUniqueName+0x79721
06eaf75c 76bb7a03 SHELL32!Ordinal733+0x2db33
06eaf7e0 76da48a1 SHELL32!InternalExtractIconListA+0xb06
06eaf82c 76da4945 SHELL32!Ordinal262+0x1d5f
06eaf874 76bb9d83 SHELL32!Ordinal262+0x1e03
06eaf8b4 76bb804b SHELL32!Ordinal866+0x1b14
06eaf930 76bb7a03 SHELL32!SHParseDisplayName+0x1d0
06eaf9b4 76bb7f24 SHELL32!InternalExtractIconListA+0xb06
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Windows\SysWOW64\comdlg32.dll - 
06eafa00 7660c9b9 SHELL32!SHParseDisplayName+0xa9
06eafa48 7660b14f comdlg32!PrintDlgExW+0x7e23
06eafeb4 7660aecb comdlg32!PrintDlgExW+0x65b9

Then I confirmed that WNetGetResourceInformation causes a DNS leak by running the CheckServer() example at https://msdn.microsoft.com/en-us/library/windows/desktop/aa385369(v=vs.85).aspx .

So next I will look into how we can use Mozilla's detour utility.

comment:73 Changed 4 days ago by cypherpunks

Georg, you as a team lead should stop this time wasting attempt to "fix" Windows. (And, maybe, file a ticket on Bugzilla about converting file dialogs to tabs as e.g. Options.)

Note: See TracTickets for help on using tickets.