Error parsing proxy.pac

[Josep Pujadas-Jubany]

Ubuntu 12.04.3 LTS 32-bit up-to-date

When using the following proxy.pac, IcedTea doesn't open embedded java applets in Firefox or Chromium:

function FindProxyForURL(url, host) {
   return "PROXY 192.168.1.3:8080; DIRECT";
}

I had to change to:

function FindProxyForURL(url, host) {
   return "PROXY 192.168.1.3:8080";
}

There is some problem passing & parsing proxy.pac configurations.

I tried using proxy.pac using system proxy configuration, browser proxy configuration and IcedTea Web Control Panel.

My conclusion is that proxy.pac only work if they return one proxy possibility (as my above example).

Similar to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1091926

[Josep Pujadas-Jubany (jpujades)]

More testing...

https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1091926/comments/11

[Michael Greene (commod0re)]

I'm having a very similar issue here.

If I tell Firefox to use a proxy file (i.e. set network.proxy.autoconfig_url = file:///etc/proxy.pac and network.proxy.type = 2), and that pacfile exists, everything works fine, even if returning two proxies.

If I then rename or remove that proxy.pac, firefox goes along on its way merrily, but the IcedTea plugin fails. Running firefox from the cli yields the following output:

java version "1.7.0_79"
OpenJDK Runtime Environment (IcedTea 2.5.6) (7u79-2.5.6-0ubuntu1.12.04.1)
OpenJDK Client VM (build 24.79-b02, mixed mode, sharing)
Unable to use Firefox's proxy settings. Using "DIRECT" as proxy type.

(plugin-container:4609): GLib-WARNING **: Invalid UTF-8 passed to g_io_channel_write_chars().
/bui/dbuildd/icedtea-web-1.2.3/build7/../plugin/icedteanp/IcedTeaNPPlugin.cc:1859: thread 0xb1f2b560: Error: Failed to write bytes to output channel: Invalid byte sequence in conversion input

[Michael Greene (commod0re)]

A real oddity to me is that if I put the plugin into debug mode before running firefox it all works:

$ export ICEDTEAPLUGIN_DEBUG=true
$ firefox --new-instance 2>&1 | tee /tmp/ffdebug.log

(will attach log momentarily)

after downloading the source package and poking around, I found this code:

        gchar* proxy;
        uint32_t len;

        gchar* decoded_url = (gchar*) calloc(strlen(parts[4]) + 1, sizeof(gchar));
        IcedTeaPluginUtilities::decodeURL(parts[4], &decoded_url);
        PLUGIN_DEBUG("parts[0]=%s, parts[1]=%s, reference, parts[3]=%s, parts[4]=%s -- decoded_url=%s\n", parts[0], parts[1], parts[3], parts[4], decoded_url);

        gchar* proxy_info;

#if MOZILLA_VERSION_COLLAPSED < 1090100
 proxy = (char*) malloc(sizeof(char)*2048);
#endif

        proxy_info = g_strconcat ("plugin PluginProxyInfo reference ", parts[3], " ", NULL);
        if (get_proxy_info(decoded_url, &proxy, &len) == NPERR_NO_ERROR)
          {
            proxy_info = g_strconcat (proxy_info, proxy, NULL);
          }

        PLUGIN_DEBUG("Proxy info: %s\n", proxy_info);
        plugin_send_message_to_appletviewer(proxy_info);

        g_free(decoded_url);
        decoded_url = NULL;
        g_free(proxy_info);
        proxy_info = NULL;

#if MOZILLA_VERSION_COLLAPSED < 1090100
 g_free(proxy);
 proxy = NULL;
#endif

note that proxy is only allocated if MOZILLA_VERSION_COLLAPSED < 1090100 (is not even initialized otherwise), but is used if get_proxy_info succeeds, so on the first invocation we get (potentially) garbage output like so:

plugin PluginProxyInfo reference 0 �Þ

for whatever reason, having debugging enabled causes this not to happen (perhaps a side-effect of the fprintf call inside the PLUGIN_DEBUG macro? I'm not really sure)

Anyway, I am building a possible patch for this right now and will submit once I have verified that it works as I expect it to.

[Michael Greene (commod0re)]

Looks like that was actually only about 95% of the way to the bug. Here's the real issue, one call further in, in the get_proxy_info function:

      gpointer instance=getFirstInTableInstance(instance_to_id_map);
      browser_functions.getvalueforurl((NPP) instance, NPNURLVProxy, siteAddr, proxy, len);

looking at the docs for that function (NPN_GetValueForURL), the signature is:

NPError NPN_GetValueForURL(NPP instance, NPNURLVariable variable, const char *url, char **value, uint32_t *len);

and an important point called out for the value parameter:

*Note: the value may have internal NULL bytes and may not be NULL-terminated.*

importantly, neither the return value nor len are actually checked before moving on and attempting to use the value.

When Firefox is set to use a PAC file that doesn't exist, the function call fails, no allocation happens for **value (leaving whatever garbage was in memory before), len is set to 0, but IcedTea disregards that and continues on as though it succeeded, and concatenates random memory garbage to the plugin PluginProxyInfo string that is to be sent over to the java process.

Back in the previous function call, it is enough to work around the bug by changing gchar* proxy; to gchar* proxy = NULL;, but it is perhaps only partially correct. Attached here is a patch that resolves the issue in my case.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "fix_invalid_byte_sequence.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Tiago Stürmer Daitx (tdaitx)]

Created attachment 1445
handle error when NPN_GetValueForURL call fails

Original bug report: https://bugs.launchpad.net/ubuntu/+source/icedtea-web/+bug/1222912

Here's the real issue, one call further in, in the get_proxy_info function:

      gpointer instance=getFirstInTableInstance(instance_to_id_map);
      browser_functions.getvalueforurl((NPP) instance, NPNURLVProxy, siteAddr, proxy, len);

looking at the docs for that function (NPN_GetValueForURL), the signature is:

NPError NPN_GetValueForURL(NPP instance, NPNURLVariable variable, const char *url, char **value, uint32_t *len);

and an important point called out for the value parameter:

*Note: the value may have internal NULL bytes and may not be NULL-terminated.*

importantly, neither the return value nor len are actually checked before moving on and attempting to use the value.

When Firefox is set to use a PAC file that doesn't exist, the function call fails, no allocation happens for **value (leaving whatever garbage was in memory before), len is set to 0, but IcedTea disregards that and continues on as though it succeeded, and concatenates random memory garbage to the plugin PluginProxyInfo string that is to be sent over to the java process.

Back in the previous function call, it is enough to work around the bug by changing gchar* proxy; to gchar* proxy = NULL;, but it is perhaps only partially correct. Attached here is a patch that resolves the issue in my case.

[Jvanek (jvanek)]

Pushed. Will be in next 1.6 release. TY for patch.

For curiosity, what was your base for this patch? The initilization hunks failed, because the ariabels were mostly already initialised... If you can, cahn you chek against head?

[Tiago Stürmer Daitx (tdaitx)]

Michael Greene (mgreene-l in Launchpad) provided the patch in https://bugs.launchpad.net/ubuntu/+source/icedtea-web/+bug/1222912

I will check if he can test against icedtea-web head.

Thank you very much!

[Tiago Stürmer Daitx (tdaitx)]

Michael, thank you for taking the time to report this bug and helping to make Ubuntu better.

Your patch was highly appreciated and is now applied on IcedTea upstream. Would you be willing to test icedtea-web head? Can you build it yourself? Or would you rather grab a pre-build deb file, either directly or from a ppa?