Update Start page via snippets or main page to notify users to upgrade to latest version of Java.

In particular, we might want to have some javascript that looks through navigator.plugins, something like: for (var i = navigator.plugins.length - 1; i >= 0; --i) { if (navigator.plugins[i].name.indexOf("Java") == 0) { /* does this work for all java plugins */ var versionStr = navigator.plugins[i].name.split(" ")[2]; /* parse the version number somehow , figure out if it's a vulnerable version, and alert somehow (document.write?) */ } }

Rafael, did anything ever come of our call for help in that last meeting with the start page folks?

Is this still valid?

Yes, this is still valid. Every Firefox who has reported being hacked has been hacked through Java. This was recently confirmed independently by reporters who surfed lots of sites using IE and Firefox in default configurations and found Firefox got hacked less, and when it was it was always through Java. Frankly I think we should just turn it off.

Oh, and in addition to the 1.4.2_05 and earlier exploit that's been used, Sun recently announced a bunch of vulnerabilities up through 1.5.0_05 and there's some anecdotal evidence those are being used, too.

Rafael owns start page updates. Raf - can you please review this bug and figure out next steps?

now that flash has drive-by remote code exection possible for flash player 8.0.22.0 and below http://secunia.com/advisories/19218/ we should consider adding a flash sniff too. http://www.macromedia.com/software/flash/about/ has sniffing code that might be lifted for flash player version detection. <!-- $RCSfile: FlashDetection2k.pm,v $ $Revision: 1.71 $ : server can't tell if your browser has Flash; you have a Netscape-like browser, here is some client-side JavaScript to detect if you have Flash. --><script type="text/javascript" language="JavaScript"> <!-- start JS detection FlashMode = 0; if (navigator.plugins && navigator.plugins.length > 0) { if (navigator.plugins["Shockwave Flash"]) { var plugin_version = 0; var words = navigator.plugins["Shockwave Flash"].description.split(" "); for (var i = 0; i < words.length; ++i) { if (isNaN(parseInt(words[i]))) continue; plugin_version = words[i]; } if (plugin_version >= 6) { var plugin = navigator.plugins["Shockwave Flash"]; var numTypes = plugin.length; for (j = 0; j < numTypes; j++) { mimetype = plugin[j]; if (mimetype) { if (mimetype.enabledPlugin && (mimetype.suffixes.indexOf("swf") != -1)) FlashMode = 1; // Mac wierdness if (navigator.mimeTypes["application/x-shockwave-flash"] == null) FlashMode = 0; } } } } }

Raf - any updates on whether we can push out notifications like this to affected Java/Flash users?

This can be used as the basic detection script. "if hasOldJava() <put up java msg>" and "if hasOldFlash() <put up flash msg>" The messages should be prominent (red boxes?) and link to the vendor sites to get the updates (yes, we have the plugin finder service, but we can't really trigger it from the start page in this way). http://www.java.com/ http://www.macromedia.com/shockwave/download/download.cgi?P1_Prod_Version=ShockwaveFlash (could link to macromedia homepage, less danger of future broken links, but it's a cluttered page and hard to find the free flash player download)

Looks like not all platforms have 8.0 r24 as the latest, some use 7.0 r63 http://www.macromedia.com/software/flash/about/ The sniffing code in the attachment will have to be adjusted by platform. We don't have to worry about Mac classic, so I think it's just *nix versions using the older-branch update.

any international issues to consider if we do this? I'm guessing each localization is firewalled on the start page side.... where to point users once an old version is detected might need some research for each local...

Shockwave for director is also affected, 10.1r16 contains the fix, 10.1r11 and earlier are vulnerable. Unfortunately unlike flash they don't put the release number in the plugin name or description, both versions simply say 10.1

(In reply to comment #12) > where to point users once an old version is detected might need > some research for each local... I don't know about adobe/macromedia, but www.java.com redirects me to www.java.com/en/ so there's some language sniffing there that should cover it.

Checking-in with the start page team on how to go about doing this.

Another URL that may be good to link to is http://www.macromedia.com/go/getflash

Lets not reinvent the wheel. PluginFinderService has all of the plugins we support and where to get them. http://lxr.mozilla.org/update1.0/source/plugins/PluginFinderService.php

For the record, we're also looking at adding the ability to block vulnerable plugins from being intstantiated, and that would most likely also include notifications to the user when plugins do get blocked. Once done, a user that's got a vulnerable flash player would simply get the plugin finder UI when loading a page with flash, and that way be able to download an updated plugin, provided one exists etc.

https://bugzilla.mozilla.org/show_bug.cgi?id=337768 points out the need to get going on some solutions for this soon.

See also bug 271559.

Hey folks -- Ownership of start page snippets has moved to me. Is this still an issue? (Update Start page via snippets or main page to notify users to upgrade to latest version of Java.) -Paul

Yes, it is definitely still an issue -- a BIG issue. In the code snippet attached JAVA_UPDATE should be changed from 6 to 7 FLASH_VER should be 9.0 FLASH_SUBVER should now be 16 The Linux flash verson is unchanged -- they're still vulnerable :-( We may want to consider adding checks for QuickTime and Real -- both have had pretty nasty holes also, though I haven't heard they're being exploited in the wild unlike Flash and Java which definitely are being attacked.

It seems like it might be pretty desireable to have the checks happen on the Mozilla side before the redirect to Google so that Mozilla can hijack the home page and send the user to a page on mozilla.com. Can this be done without slowing down all start page loads?

No. That would require a redirect rather than a CNAME.

As in all comments today, my brain is off. We'd need an approval from google to do js-magic on the startpage, which would, AFAICT, be required to do any warning about particular plugins. One way to do that would be to create an on-topic special snippet, that may or may not be to work through with the lack of change management for the start pages. PS: I don't have an up-to-date report on the start page snippets and the update on google.

jay, maybe we should hook up talkback auto responders to any plugin related crash to also instruct users to update to the most recent plugins for for improved security and stability...

Chofmann: That is a good idea, but not sure if I'll be able work on that with 1.5.0.x adn 2.0 tasks on my plate. If you can please log a bug, that will be great and hopefully I can get to it sooner than later. The autoresponder code is old and not hooked up, and most likely broken right now... so will have to rewrite some of it.

We're also getting reports of people being hacked through vulnerable WMP, appear to be using the MS06-006 flaw: http://www.microsoft.com/technet/security/Bulletin/MS06-006.mspx http://www.symantec.com/security_response/writeup.jsp?docid=2006-011115-4414-99 Symantec gives it a Damage Level of "low", but it's being used to drop Trojans on people's machines. Unfortunately there's no way to check the version of Npdsplay.dll from the existing plugin interface available to scripts.

Re-awakening. Our newish strategy is to stick some alerts on the first-run and "you've been updated" pages. These alerts will lead to a general-use plug-in check page, similar to http://www.guninski.com/mozbugs/plug-test.html (from bug 271559) . Handy for everyone, eh? My first pass at summarizing/attacking this is available here: http://wiki.mozilla.org/PluginUpdating AFAICT, PFS will not be able to provide such updates. I'm proposing we hack out something extensible that will initially check for just Flash and Java -- adding links to this page on our common, easily controllable, landing pages (first run, updated). I'm seeking feedback on the overall plan, particularly on how to keep track of the latest secure versions.

It's probably best to do this off of a timeout so it doesn't hurt the rendering time of the page. Loading plugins (in order to populate navigator.plugins) takes a while the first time each session, IIRC.

I've filed bug 391433, in an attempt to get the production scripts created. We'll probably farm this out -- but if anyone wants to take a stab at it, feel free :)

The recent hype on the Flash malloc failure problems (http://documents.iss.net/whitepapers/IBM_X-Force_WP_final.pdf) caused me to actually look at my Flash plugin recently and note that it was woefully out-of-date. Since I run Minefield I'd never see any of these warnings, which made me wonder what would other users do who either change too quickly or too slowly than the "normal" user. Is there anything beyond the First Run or "You've been updated" pages being looked at as a checking mechanism? Since AMO provides Add-on Version Update checking, would it be possible to extend that update concept to cover Plugins as well? My Bugzilla-fu is not what it used to be, but I couldn't find anything open covering that.

We're not ever going to put this on the Google-hosted start page. This concept has been carried on in other bugs, however, such as upyourplug and other server-side and client features.