Disable WPAD DNS devolution by default

[GoogleCodeExporter]

The attached patch against trunk disables WPAD DNS devolution by default.
It can be activated at build time by passing --with-wpad-dns to configure.

This is to address some security implications DNS proxy devolution has. See
for example:

http://lists.debian.org/debian-devel/2008/12/msg00730.html (full thread)
http://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol#Security

Original issue reported on code.google.com by pochu27@gmail.com on 7 Jan 2009 at 9:50

Attachments:

• libproxy_disable_wpad_dns_devolution_by_default.patch

[GoogleCodeExporter]

Second try (thanks Nathaniel!)

Original comment by pochu27@gmail.com on 7 Jan 2009 at 11:32

Attachments:

• libproxy_disable_wpad_dns_devolution_by_default.patch

[GoogleCodeExporter]

Hi,

Wasn't aware of pochu's patch; I came up with disabling WPAD fall back by 
default and
adding an env var override instead.

Cheers,

Original comment by loic.min...@gmail.com on 9 Jan 2009 at 4:37

Attachments:

• 50_px-wpad-fallback-env-var.patch

[GoogleCodeExporter]

My opinion, for what it's worth:

I'm not to happy with all the approached of envvar, and especially not for this 
case. 
I'd prefer this being implemented based on a conf file (/etc/libproxy.conf) 
where we
could possibly enabled / disable features like wpad.

The advantage is easy administration, compared to the difficulty with envvar. 
Environment is 'more difficult' to configure for typical home-use-case if you 
want it
to be working for all the applications that are typically started from a 
launcher (of
course, we can all open a console, type export proxy_pad=1 domycommand, but is 
THIS
what we're targeting? in order for libproxy to be taken serious for distros, it 
has
to 'just work', especially for the end user. And user x should not have to mess 
with
envvars when his admin defines that wpad is a no go or if his admin says he 
needs it.

Just my 0.02$

Original comment by dominiqu...@gmail.com on 21 Jan 2009 at 8:37

[GoogleCodeExporter]

Summary of our discussion on IRC:

We all agree we need the distributor to be able to disable wpad fallback

The question is whether we want the local administrator to be able to change
(enable/disable) that

In case we go the /etc/libproxy.conf route, that could be distributor setting 
it to
disabled, and then local admin to enabled if they wish, for example

And the other question is whether we want to look at the user config so that we 
look
first at the system config, and pick its value, and if it's not "forced", we 
also
look at the user config

Original comment by pochu27@gmail.com on 21 Jan 2009 at 11:44

[GoogleCodeExporter]

Here is another variation. This patch:

1) makes libproxy no longer fall back to WPAD if an internal error occurs (such 
as a
plugin returning an invalid URL).

2) creates a "wpad-fallback" plugin, makes it configurable 
(--without-wpad-plugin),
and moves the "fall back to wpad://" code from proxy_factory.c to there.

3) tweaks config_order handling to keep the plugin ordering correct 
(wpad-fallback
needs to be run last). After considering the idea of adding
PX_CONFIG_CATEGORY_FALLBACK, I eventually decided to just make it so that
PX_CONFIG_CATEGORY_NONE plugins don't get run unless they are listed 
explicitly, and
then changed the default order to:

  #define DEFAULT_CONFIG_ORDER "USER,SESSION,SYSTEM,envvar,wpad-fallback"

(which, assuming you didn't pass --without-wpad-fallback, results in exactly 
the same
behavior as before)

One issue with this is that if the wpad-fallback plugin is installed, there's 
still
no easy way stop it from getting used as a plugin-of-last-resort (proxy.conf and
PX_CONFIG_ORDER only allow you to prepend things to the beginning of the
config_order; you can't *remove* something from it). One way to do this without
changing the way config_order works would be to add a "direct" plugin, that just
returns "direct://" for any URL; if you put that into the config_order anywhere
before wpad-fallback, it would block wpad-callback from ever getting run.

Adding all these teeny tiny plugins seems a little silly though. Perhaps the 
plugins
that don't depend on any external libraries should be moved into the library 
itself?
They could still be individually-configurable of course, it's just that keeping 
them
in libproxy.so would save some readdir() and dlopen() time...

Original comment by dan.wins...@gmail.com on 9 Feb 2009 at 9:13

Attachments:

• wpad-fallback.diff

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I'm now working on integrating libproxy into Solaris.
I found the above patch wpad-fallback.diff does not work for the 0.2.3 tarball.
I did some modifications and attached a new patch

Original comment by ke.w...@sun.com on 13 Feb 2009 at 8:31

Attachments:

• wpad-fallback.diff

[GoogleCodeExporter]

Does any of the above patches look good enough?

Original comment by pochu27@gmail.com on 1 Mar 2009 at 10:16

[GoogleCodeExporter]

This is based on Loïc's patch, but actually tested :)

I'm using it for the Debian and Ubuntu packages for now as a temporary measure.

Original comment by pochu27@gmail.com on 2 Mar 2009 at 11:49

Attachments:

• 50_px-wpad-fallback-env-var.patch

[GoogleCodeExporter]

The real solution here is to move wpad functionality into a set of plugins.  
This
should be broken down as:
   1. wpad_dns
   2. wpad_dns_devolution
   3. wpad_slp
   4. wpad_dhcp

You could then disable WPAD altogether or just portions of the protocol.  Now 
that
the PluginManager has landed, this is now technically possible.  I'll gladly 
accept
patches. :)

Original comment by npmccallum@gmail.com on 17 Mar 2009 at 9:13

[GoogleCodeExporter]

In trunk, all wpad stuff is now implemented as plugins.  If you don't want
devolution, don't install wpad_dnsdevolution.

Original comment by npmccallum@gmail.com on 19 Mar 2009 at 1:40

• Changed state: Fixed
• Added labels: Milestone-Release0.3

[GoogleCodeExporter]

pochu27,

We got reports that libproxy does not work on Ubuntu.
I tracked it down and COULD indeed identify the culprit:
Your patch 50_px-wpad-fallback-env-var.patch, as also attached here, breaks the
library if PX_WPAD_FALLBACK is not set.

@@ -591,7 +608,12 @@ px_proxy_factory_get_proxies (pxProxyFac
    }

    // If the config plugin returned an invalid config type or malformed URL, fall back
to 'wpad://'
-   if (!(!strncmp(config->url, "http://", 7) || 
+   if (!do_wpad_fallback)
+   {
+       fprintf(stderr, "*** Config plugin returned invalid URL type and WPAD 
fallback
disabled! Falling back to direct...\n");
+       goto do_return;
+   }
+   else if (!(!strncmp(config->url, "http://", 7) || 
          !strncmp(config->url, "socks://", 8) ||
          !strncmp(config->url, "pac+", 4) ||
          !strcmp (config->url, "wpad://") ||

I would sat the check for do_wpad_fallback should be AND linked to all the other
checks, thus if all those fail AND we want to fall back, then we do so.

Original comment by dominiqu...@gmail.com on 3 Apr 2009 at 6:41