a 0-day in java was discovered that is already used in targeted attacks see http://www.deependresearch.org/2012/08/java-7-0-day-vulnerability-information.html so requesting blocklisting java (This vulnerability affects Java 7 (1.7) Update 0 to 6. Does NOT affect Java 6 and below) 7 till oracle has published a patch to keep our users safe
And it's now been added to metasploit which will ensure it spreads even faster. https://community.rapid7.com/community/metasploit/blog/2012/08/27/lets-start-the-week-with-a-new-java-0day This one's a trickier call than the last blocklist event because there's currently no patch affected users can go get if they need a working JRE (for example, to access a required work-related web app on an intranet). Hopefully they could downgrade to the most recent version of Java 6. On the other hand Oracle is unlikely to patch this ahead of their scheduled October update and that's plenty of time for evil-doers to profit if we don't block until then. If Oracle sticks to that schedule waiting a couple of weeks until the malware gets out of hand to block it doesn't make the block any less disruptive, and fails to protect millions in the meanwhile.
We haven't decided if we're going to push this live, but we better be ready if we do. So I have staged the blocks for QA to test. Windows https://addons-dev.allizom.org/en-US/firefox/blocked/p125 Linux https://addons-dev.allizom.org/en-US/firefox/blocked/p127 This is a softblock (level 1) that should disable the plugin if you are using Java 7 (up to update 6). This doesn't affect any versions of the Java 6 branch, and therefore there's no need to block on Mac OS X.
Confirmed blocklist working on Linux and Windows with JRE 1.7u6, 1.7u5, and 1.7. Also confirmed that JRE 1.6u34 does not get blocklisted. Finally, confirmed that user can opt out of the block during or after blocking. Removing QAWANTED for now. I'll verify if/when we decide to push this live.
(In reply to Jorge Villalobos [:jorgev] from comment #3) > This doesn't affect any versions of the Java > 6 branch, and therefore there's no need to block on Mac OS X. That's not the correct conclusion to draw. The Java that is provided with OS X is Java 6, but newer versions of OS X do not come with Java. Which means that users of those systems download and install Java 7 from Oracle.
This is not a solution to this new Java Zero day vulnerability on mozilla firefox, the description of this issue must be shown there below: A vulnerability has been discovered in Oracle Java, which can be exploited by malicious people to compromise a user's system. The vulnerability is caused due to an error in how the "setSecurityManager()" function can be called, which can be exploited by an applet to set its own privileges to e.g. allow downloading and executing arbitrary programs. Successful exploitation allows execution of arbitrary code. NOTE: This is currently being actively exploited in targeted attacks. The vulnerability is confirmed in version 7 update 6 build 1.7.0_06-b24. Other versions may also be affected.(1) site: http://secunia.com/advisories/50133/ and other statement from Americas Computer Emergency response team is found below on the following site http://www.kb.cert.org/vuls/id/636312 Please add further java block mitigations on mozilla firefox as soon as possible, This Zero day vulnerability (CVE-2012-4681) is being exploited in wild.
(In reply to WD from comment #5) > That's not the correct conclusion to draw. The Java that is provided with > OS X is Java 6, but newer versions of OS X do not come with Java. Which > means that users of those systems download and install Java 7 from Oracle. I wasn't aware that Mountain Lion had dropped Java. It appears that if you try to run it, the OS recommends that you install JRE 6, which is safe for this exploit. It is true that many users will try to get the latest version and end up with JRE 7, though. Thanks for the note.
All reports indicate IBM Java 7 is vulnerable but IcedTea isn't. Either IBM Java needs to be blocklisted too or IcedTea needs to be whitelisted, depending on the method.
Neither one is included at the moment. We're in touch with IBM about this and they'll most likely deal with the problem on their own.
IdedTea 2 up to 2.3.0 is vulnerable too, see http://gnu.wildebeest.org/blog/mjw/2012/08/30/java-bug-cve-2012-4681/ so I think IcedTea 2.0 up to 2.3.0 should be blacklisted too.
(In reply to heinz.repp from comment #11) > IdedTea 2 up to 2.3.0 is vulnerable too, see > http://gnu.wildebeest.org/blog/mjw/2012/08/30/java-bug-cve-2012-4681/ > > so I think IcedTea 2.0 up to 2.3.0 should be blacklisted too. indeed, jorge do we want to deal with that in that bug or shall i file a new one for icedtea block 2>2.3.0 ?
Please file a separate bug. Since IcedTea already has a fixed version, I can move forward with that block. Please include the plugin information from about:plugins.
Quick heads up to everyone involved: Oracle released an updated version of Java 7 that fixes the vulnerability, so we will block the Java plugin very soon.
Please move forward with infobar, not softblock. Since an update is available that addresses the security concern, the consensus is to move forward with an infobar to educate users they need to apply the update. We'll also do other outreach via the plugincheck website, about:home snippets, and security blog
Anthony, I've updated both staged blocks so that they are infobar instead of regular softblocks. Please give them a try to make sure they are working correctly.
The staged block is missing the severity property which causes Java to be hard-blocked and does not show a notification bar. <pluginItem blockID="p125"> <match exp="Java\(TM\) Platform SE 7 U[5-6](\s[^\d\._U]|$)" name="name"/> <match exp="npjp2\.dll" name="filename"/> </pluginItem> Adding <versionRange severity="0"/> and deleting my addons.sqlite and pluginreg.dat causes the notification bar to appear as expected. See bug 787222.
QA has completed the testing and the notification bar is working as expected. Please see our etherpad for details specific to our testing. We can push this live with one caveat. PFS reports 7u6 as "out of date" instead of "vulnerable" (see bug 787136 comment 10). I don't think this effects the block nor does it invalidate any of our testing. It could delay when we push live though since it might downplay the severity of updating for some users.
Sorry, forgot to add the etherpad URL: https://etherpad.mozilla.org/java-0day-20120830
The info bar block is now live. https://addons.mozilla.org/en-US/firefox/blocked/p132 (Linux, Oracle JRE only) https://addons.mozilla.org/en-US/firefox/blocked/p134 (Windows) We'll extend the block to Mac OS X (comment #5), and the IcedTea plugin (comment #11), most likely next week. I'll file separate bugs for them.
Not sure if this takes time to sync but the live block is not working yet.
It took about an hour, but it's working now.
Verified that it's working on my end as well.
Maybe small typo.. https://addons.mozilla.org/en-US/firefox/blocked/p134 "Who is affected? All Firefox user who have the Java 7 plugin, update 6 and below." "user" -> "users"?
I've fixed it, thanks.
Disabling the Java Plug-in isn't sufficient to disable Java. The Java Deployment Toolkit should be disabled as well. See: http://www.kb.cert.org/vuls/id/636312 re-opening
(In reply to WD from comment #26) > Disabling the Java Plug-in isn't sufficient to disable Java. The Java > Deployment Toolkit should be disabled as well. See: > http://www.kb.cert.org/vuls/id/636312 > > re-opening We haven't disabled the Java plugin yet. All we've done is prompt users to update to the latest version. It is unclear to me if this kind of block would work with the JDT, and it would be redundant with the current block, since updating Java should fix both. If and when we decide the disable the plugin, we will also consider the JDT. Thank you for the heads up.