Error parsing proxy.pac

More testing...

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

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

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.

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.

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.]

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?