Last Comment Bug 785837 - (CVE-2012-4681) java 0-day - request for blocklisting java
(CVE-2012-4681)
: java 0-day - request for blocklisting java
Status: VERIFIED FIXED
:
Product: Toolkit
Classification: Components
Component: Blocklisting (show other bugs)
: unspecified
: All All
: -- normal with 2 votes (vote)
: ---
Assigned To: Jorge Villalobos [:jorgev]
: Anthony Hughes (:ashughes) [GFX][QA][Mentor]
: Jorge Villalobos [:jorgev]
Mentors:
http://cve.mitre.org/cgi-bin/cvename....
: 786321 786744 (view as bug list)
Depends on: 787136 787217 787222
Blocks: 794247
  Show dependency treegraph
 
Reported: 2012-08-27 04:45 PDT by Carsten Book [:Tomcat]
Modified: 2016-03-07 15:30 PST (History)
29 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Carsten Book [:Tomcat] 2012-08-27 04:45:42 PDT
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
Comment 1 Daniel Veditz [:dveditz] 2012-08-27 14:05:51 PDT
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.
Comment 2 Jorge Villalobos [:jorgev] 2012-08-28 09:51:41 PDT
*** Bug 786321 has been marked as a duplicate of this bug. ***
Comment 3 Jorge Villalobos [:jorgev] 2012-08-28 11:05:34 PDT
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.
Comment 4 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-08-28 12:24:45 PDT
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.
Comment 5 WD 2012-08-29 11:00:39 PDT
(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.
Comment 6 Scoobidiver (away) 2012-08-29 11:31:30 PDT
*** Bug 786744 has been marked as a duplicate of this bug. ***
Comment 7 autismm 2012-08-29 11:34:14 PDT
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.
Comment 8 Jorge Villalobos [:jorgev] 2012-08-29 11:40:08 PDT
(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.
Comment 9 Danny Moules 2012-08-29 15:07:58 PDT
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.
Comment 10 Jorge Villalobos [:jorgev] 2012-08-29 17:58:24 PDT
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.
Comment 11 heinz.repp 2012-08-30 04:54:20 PDT
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.
Comment 12 Carsten Book [:Tomcat] 2012-08-30 05:17:10 PDT
(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 ?
Comment 13 Jorge Villalobos [:jorgev] 2012-08-30 08:19:44 PDT
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.
Comment 14 Jorge Villalobos [:jorgev] 2012-08-30 13:08:09 PDT
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.
Comment 15 Michael Coates [:mcoates] (acct no longer active) 2012-08-30 13:38:40 PDT
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
Comment 16 Jorge Villalobos [:jorgev] 2012-08-30 13:40:25 PDT
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.
Comment 17 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-08-30 14:50:19 PDT
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.
Comment 18 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-08-31 12:12:20 PDT
QA has completed the testing and the notification bar is working as expected. Please see our etherpad[1] 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.
Comment 19 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-08-31 12:12:43 PDT
Sorry, forgot to add the etherpad URL:
https://etherpad.mozilla.org/java-0day-20120830
Comment 20 Jorge Villalobos [:jorgev] 2012-08-31 15:27:52 PDT
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.
Comment 21 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-08-31 16:24:15 PDT
Not sure if this takes time to sync but the live block is not working yet.
Comment 22 Jorge Villalobos [:jorgev] 2012-08-31 16:34:36 PDT
It took about an hour, but it's working now.
Comment 23 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-08-31 16:42:47 PDT
Verified that it's working on my end as well.
Comment 24 Pavel Cvrcek [:JasnaPaka] 2012-09-02 04:10:37 PDT
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"?
Comment 25 Jorge Villalobos [:jorgev] 2012-09-02 09:40:44 PDT
I've fixed it, thanks.
Comment 26 WD 2012-09-04 09:53:58 PDT
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
Comment 27 Jorge Villalobos [:jorgev] 2012-09-04 13:34:41 PDT
(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.

Note You need to log in before you can comment on or make changes to this bug.