1275797 - untrusted PAC can leak https url to network via dns

Status: VERIFIED DUPLICATE of bug 1255474

(Core :: Networking, defect)

Description

[Bas Venis]

Attachment: wpad.dat

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160502172042

Steps to reproduce:

Attached are a wpad.dat and proxy.pac provisioning file. Both will work either staticly configured or served on http://wpad/wpad.dat or via DNS or configured via DHCP (Although I believe FireFox does not support DHCP WPAD discovery).

A video demonstrating the issue can be found here: https://www.youtube.com/watch?v=_jh1A0tA4PI
The POC shows how a victious password reset link at 'https://www.google.com/passwordresettoken=pocexample' could be intercepted.



Actual results:

WPAD (autoconfiguration) and proxy.pac behavior allows an attacker on the same network to intercept all full paths & GET Data of every HTTPS request made through Chrome (and other software).


Expected results:

The root-issue seems to be that for HTTPS requests, the full url including the path & parameters is passed to FindProxyForURL() which can be exfiltrated by using forced DNS resolutions using dnsResolve(). The POC automaticly encodes the URL's to a format transferable over DNS.

Comment 1

[Bas Venis]

I came accross this issue when thinkering with WPAD after seeing https://www.us-cert.gov/ncas/alerts/TA16-144A this vulnerability, and realising that wasn't the scariest part about it all.

Please note that combined with ^ that issue, this could remotely breach HTTPS on carrier/ISP level.

I have not yet found how many products and operating systems are vulnerable, but this seems to be a VERY widespread issue. I'd like to ask your help to coordinate this disclosure to other parties (e.g other browser vendors).

Feel free to contact me for more info or help with reproducing the issue.

Cheers!

Comment 2

[Bas Venis]

Needless to say, I also tested this against Firefox. It does not seem browser dependent.

Comment 3

[:Gijs (he/him)]

Reporter, did you intend to attach a second file (ie the .pac file) ? Also, can you link to the corresponding Chrome issue (which I assume exists per comment #0) and/or indicate with which other vendors you've filed reports?

Patrick / Valentin, can you take a look and/or forward to folks who can? Thanks!

Comment 4

[Bas Venis]

Attachment: poc.pac

Absolutely. Just note that the .pac is a verbatim copy of wpad.dat .
The same issue has been reported to Google at https://bugs.chromium.org/p/chromium/issues/detail?id=614897

I also plan to report this to CERT/CC today.

Comment 5

[Patrick McManus [:mcmanus]]

to Daniel. I don't believe we will do wpad by default even on windows, fwiw.

Comment 6

[Bas Venis]

Firefox supports WPAD when "use system proxy setting" (which is the default, atleast on windows).

Or, if changed from the default, (e.g by about:preferences#advanced) it still works when: 
- Set to "Auto-detect proxy settings for this network" setting. (But ONLY over DNS discovery, not over DHCPINFORM).
- Set to "Automatic proxy configuration URL" with a hardcoded wpad.dat url (as expected).

Ofcourse this won't work when set to "Manual proxy configuration" or "No proxy".

Comment 7

[Patrick McManus [:mcmanus]]

Hey Bas,

I want to say thanks for the report and while I do want to discuss our defaults (because it determines the impact of the vulnerability) I am not trying to dismsiss the issue in total if we aren't default-vulnerable.

(In reply to Bas Venis from comment #6)
> Firefox supports WPAD when "use system proxy setting" (which is the default,
> atleast on windows).

yes - use system proxy setting is the default on windows. however we historically have not honored WPAD from the system exactly because that's the default and it makes it easy to be owned (in far more severe ways than this bug details I'm sure you agree) even though IE and Chrome typically do allow wpad by default. Generally we make you configure firefox with the "autodetect" box explicitly to get wpad.

See https://bugzilla.mozilla.org/show_bug.cgi?id=621429#c29 (the bug is still open because it contemplates some other mechanism for opting in - but its back burnered.)

So I guess I need to know whether you are asserting that we do wpad out of the box or have tested it out.. I'm a bit concerned that you've tested it and our behavior has changed (conceivably due to a library change or something in win10 perhaps..)

thanks.

Comment 8

[Bas Venis]

No worries Patrick, I think I see what you mean.

The ability to evalute/execute the wpad/proxy.pac is still the same, which means that if the OS does have wpad url configured, firefox will still use it.
Which is why I would say that Firefox is "default-vulnerable".

But, functionally speaking, (and probably due to the way Firefox inherits the system proxy settings) this will fail when the Windows proxy settings are set to "Automatically detect settings". 
If you where trying to say that *home*-users probably have Windows configured to "Automatically detect settings" and thus the risk for them is mitigated, then I do agree with you.

Although then I would still suggest to disable WPAD completely when set to "use system proxy setting".

Comment 9

[Patrick McManus [:mcmanus]]

I think the best characterization for this bug, and I say that in the sense of getting the right fix, is that a pac file can leak to the network the URL information of https transactions which we normally consider end to end opaque.

wpad is rather secondary to that - you can be subverted by a bad pac and certainly wpad mimt is one of several ways to pull off that trick (explicit pac not served via https is another) but they should at least require some kind of administrative action to take on that increased risk.

fair?

Comment 10

[Bas Venis]

I think that is fair.

IMHO, both proxy.pac and wpad are use huge cluster headache.

For the proxy.pac 'engine', I really think FindProxyForURL(url,host) should just receive a stripped url (https://hostname.tld/).
This particular POC uses dnsResolve() to leak the data, but since global variables are persistent between different requests there are lots of other ways to exfiltrate this data.

For WPAD, serving the wpad.dat over https would be a good first. Although in most settings where the pac is served on intranet, this would require a valid https certificate for intranet domains or a self-signed certificate in the trust root of the client, both might be tricky or kinda defy the whole 'automatic' part.

And then the attacker MitM's DNS or DHCP and we'd still be back to square 0. (Ok, firefox won't be defeated by DHCP)
In the current situation, proxy.pac & wpad just don't mix nicely with https.

Comment 11

[Bas Venis]

I have just heard from the chromium team they have a duplicate of my reported issue https://bugs.chromium.org/p/chromium/issues/detail?id=593759 and includes a proposed fix inside the pac engine itself which has been applied to chrome canary.

Given any kind of change would break some kind of functionality, it might be worth to implement a fix similar enough. (wpad clients don't send useragent to the server)

Comment 12

[Patrick McManus [:mcmanus]]

I can't see those chrome bugs (permissions), but I suspect we have a similar thing and were planning to do what chrome does - we were aware of that. iirc it isn't exactly the same so I didn't dup it yet (but I know daniel is following the details and will if he feels there isn't anything additional to do).

Comment 14

[Bas Venis]

Can we make this report public? Would like to use it as reference in a debate about the efficiency of reporting directly to Mozilla.