743446 - Incorrect Firefox error message while blocking IBM Java Plug-in

Status: RESOLVED FIXED

(Toolkit :: Blocklist Policy Requests, defect)

Description

[Priyanka]

Attachment: Warning message shown by firefox while blocking IBM java plugin

User Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28
Build ID: 20120306064154

Steps to reproduce:

While starting latest  Firefox with IBM java plugin installed , Firefox is block listing IBM java plugin with warning message as  seen in the  attached screen shot 


Actual results:

As per the following bugzilla work-item, Mozilla mandates the inclusion of latest Oracle Critical Patch Update for Java Plug-in.

https://bugzilla.mozilla.org/show_bug.cgi?id=739955

The current fix for this bug checks whether Oracle Critical Patch Update is available in a particular Java version based on the file version information of the Java plug-in dll (npjp2.dll). However, this approach does not work for other Java vendors like IBM who use a different file versioning standard. Hence, FireFox will block other vendor's Java even if the Oracle Critical Patch Update is available in it. 

This is very critical issue for IBM and has to be addressed with top most priority. Please let us know if Mozilla team requires any more information from IBM Java team to modify the validation check or the warning message.  

Also, we would like to get the following information to mitigate the impact of this vulnerability to IBM customers:-

1) Whether Firefox mandated the February Oracle Critical Patch Update only because of the critical patch CVE-2012-0507 (http://www.oracle.com/technetwork/topics/security/javacpufeb2012-366318.html). If the mandate included other critical patches that were included as part of Oracle's 2012 February advisory, please provide us with the details of those.
2) Versions of Mozilla FireFox that are affected by this vulnerability

3) How would Mozilla address the version check validation mechanism which is compatible with other Java vendors like IBM?

4) What is Mozilla's plan to have a warning message which is compatible to other Java vendors like IBM? (May be you can recommend users to contact the Java vendors directly to get the availability of the Oracle Critical Patch Update.) 



Expected results:

Mozilla should consider file version information of  the Java plug-in dll (npjp2.dll) of other Java vendors like IBM while block listing the java plugin

Comment 1

[Kev Needham [:kev]]

Can we get a copy of the JRE IBM deploys? THe block checks for the plugin filename and then the version of that DLL. Is there version information within the DLL that is readily available and different from the Oracle-provided version?

(In reply to Priyanka from comment #0)
> Created attachment 613106 [details]
> Warning message shown by firefox while blocking IBM java plugin
> 
> User Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28)
> Gecko/20120306 Firefox/3.6.28
> Build ID: 20120306064154
> 
> Steps to reproduce:
> 
> While starting latest  Firefox with IBM java plugin installed , Firefox is
> block listing IBM java plugin with warning message as  seen in the  attached
> screen shot 
> 
> 
> Actual results:
> 
> As per the following bugzilla work-item, Mozilla mandates the inclusion of
> latest Oracle Critical Patch Update for Java Plug-in.
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=739955
> 
> The current fix for this bug checks whether Oracle Critical Patch Update is
> available in a particular Java version based on the file version information
> of the Java plug-in dll (npjp2.dll). However, this approach does not work
> for other Java vendors like IBM who use a different file versioning
> standard. Hence, FireFox will block other vendor's Java even if the Oracle
> Critical Patch Update is available in it. 
> 
> This is very critical issue for IBM and has to be addressed with top most
> priority. Please let us know if Mozilla team requires any more information
> from IBM Java team to modify the validation check or the warning message.  
> 
> Also, we would like to get the following information to mitigate the impact
> of this vulnerability to IBM customers:-
> 
> 1) Whether Firefox mandated the February Oracle Critical Patch Update only
> because of the critical patch CVE-2012-0507
> (http://www.oracle.com/technetwork/topics/security/javacpufeb2012-366318.
> html). If the mandate included other critical patches that were included as
> part of Oracle's 2012 February advisory, please provide us with the details
> of those.
> 2) Versions of Mozilla FireFox that are affected by this vulnerability
> 
> 3) How would Mozilla address the version check validation mechanism which is
> compatible with other Java vendors like IBM?
> 
> 4) What is Mozilla's plan to have a warning message which is compatible to
> other Java vendors like IBM? (May be you can recommend users to contact the
> Java vendors directly to get the availability of the Oracle Critical Patch
> Update.) 
> 
> 
> 
> Expected results:
> 
> Mozilla should consider file version information of  the Java plug-in dll
> (npjp2.dll) of other Java vendors like IBM while block listing the java
> plugin

Comment 2

[Riju Reghunath]

From:	Kev Needham <[e-mail]>
To:	Riju Reghunath/India/IBM@IBMIN

Hi Riju,

Can you please point me to a site where I can download the JRE for the 
IBM version? I've tried navigating IBM's website but have found them to 
be more than a little frustrating.

The issue we have with the version detection and some JREs is that 
everyone uses the same filename, but doesn't maintain the same version 
strings. We need some way to uniquely identify the JRE file to separate 
it out from the block.

If you could let me know where to download the JRE in question, it'd 
help us find that. We can push the change out relatively quickly, we 
just need to see a sample to determine if we can differentiate from 
Oracle's version.

Thanks,
kev

Comment 3

[Riju Reghunath]

Riju Reghunath 	to:	Kev Needham

Hi Kev,

With IBM JDK we don't upgrade shared modules (dll/so) file version with each drop. We are following a different upgrade levels, 'Service Refreshes' (major upgrade) and 'Fix Packs' (minor upgrade) compared to Oracle JDK updates.  With this approach IBM JDK has the ability to provide fix / patch on any existing JDK level (interim Fix) instead of upgrading.  As checking the deploy dll file version will not work with IBM JDK we recommend Mozilla to consider all these factors while checking the IBM JDK version which has the vulnerability fix or not.

In IBM JDK, the best place to look for the JDK version for the validation is javasdkversion.properties file in rt.jar under jre/lib folder.  

For example,  javasdkversion.properties of an interim fix build is like this

sdk.version=pwi3260sr9fp1ifix-20110712_01(SR9 FP1+IZ95392+IZ95393+IZ97453+IZ95114)

Where
	pwi3260  ==>   Build for Windows OS, 32 bit Java60
	SR9           ==> Service Refresh 9
        FP1             ==> Fix pack 1 
        IZxxxxx       ==> Fix numbers provided as patch on top of fix pack 1.

The vulnerability fix is available from IBM JDK build  Java 6 SR10 FP1 and Java 7 SR1 or higher and with any lower levels build having patch fix IV15332.

Based on this version format validation of  the fix availability could be checked by following method:

- Extract   javasdkversion.properties from jre\lib\rt.jar
- Read the version string corresponding to  javasdkversion.properties
- Search for the string 'IV15332'
- If not available, parse the version string to a numeric version number  (for example 60 SR10 FP1 to 600 10 01 ,  60 SR11 to 600 11 00 ,   70SR1  to 7000100).
- Check whether the version number is <  6001001 for Java 6 and 7000100 for Java 7.   If so, throw the blocking message.

Regards
Riju

Comment 4

[Riju Reghunath]

Kev Needham <[e-mail]> to Riju Reghunath

Hi Riju,

Please also see comment 99 and comment 100 in bug 739955, as this issue 
may already be resolved (blocklists can take up to 24hrs to propagate). 
If it is not resolved, please let me know.

(https://bugzilla.mozilla.org/show_bug.cgi?id=739955#c99)

Thanks!
kev

Comment 5

[Riju Reghunath]

Riju Reghunath 	to:	Kev Needham

Hi Kev,

What is the best alternative way to check this as the previous block warning wasn't consistent across all installations?  Previous nightly build (06th April)  blocklist.xml was having a script like below
<pluginItem blockID="p80">
<match name="description" exp="[^\d\._]((0(\.\d+(\.\d+([_\.]\d+)?)?)?)|(1\.(([0-5](\.\d+([_\.]\d+)?)?)|(6(\.0([_\.](0?\d|1\d|2\d|30))?)?)|(7(\.0([_\.][0-2])?)?))))([^\d\._]|$)" /> <match name="filename" exp="(npjp2\.dll)|(libnpjp2\.so)" /> <versionRange severity="1"></versionRange>
</pluginItem> 

With recent nightly build (08th April) we are not seeing such an element with blocklist.xml, . Does this means Mozilla no longer blocks Java plug-in from any vendor ? 

Regards
Riju

Comment 6

[Riju Reghunath]

Kev Needham <[e-mail]> to Riju Reghunath

Hi Riju,

I sent you mail over the weekend about the blocklist already being 
modified this weekend, so if you're not seeing it, then the change made 
in bug 739955 (see 
https://bugzilla.mozilla.org/show_bug.cgi?id=739955#c100) has probably 
already addressed it.

kev

Comment 7

[Riju Reghunath]

Many thanks Kev.

May I request you to answer below questions, sorry if questions are repetitive as we need these answer's before we provide an update to our customer's.

1) In future, the previous attached Java plug-in warning message will no longer displayed to Firefox customer's who all uses IBM JDK as their plug-in.
  	 	
	 	
2) By when all the end customer will get new blocklist.xml updated with client browser? Is  blocklist.xml file updation is automatic and what is its frequency (for e.g  would it get updated every time Firefox is restarted if connected with network)?

Comment 8

[Barry Marshall]

Presuming Mozilla could get a copy of the IBM JRE in question to test with, is there a mechanism that exists that is able to provide the type of block test that Riju talks about in Comment 3?  Or does that need a bug opened up for that?

Also, isn't this for all branches, not just 3.6?

Comment 9

[Riju Reghunath]

Kev Needham <[e-mail]> to Riju Reghunath


> Many thanks Kev.
>
> May I request you to answer below questions, sorry if questions are
> repetitive as we need these answer's before we provide an update to our
> customer.
>
> 1) In future, the below Java plug-in warning message will no longer
> displayed to Firefox customer's who all uses IBM JDK as their plug-in.

The block should be removed, yes, but confirmation that you're seeing 
this would be great. There are also instructions on the addons blog for 
testing the blocklist update at 
http://blog.mozilla.com/addons/2012/04/04/update-on-java-blocklist/

> 2) By when all the end customer will get new blocklist.xmlupdated with
> client browser? Is blocklist.xmlfile updation is automatic and what is
> its frequency (for e.g would it get updated every time Firefox is
> restarted if connected with network)?

Firefox checks once every 24 hours and applies the blocklist changes on 
update. Any copies of Firefox should be updated at this point, or will 
be when they start up.

kev

Comment 10

[Riju Reghunath]

Riju Reghunath 	to:	Kev Needham

Hi Kev,

Thanks for your quick revert. I would like to confirm my understanding on your response as am not very clear on the context in which the terms "block" and "unblock" are used. When you say "block should be removed" are you implying that even a warning message which was being displayed earlier will not be shown with the latest nightly build or did you mean that the warning message will still be shown but the users have a choice to ignore the warning message ?

Essentially - with the latest nightly build will users see the warning message "Java plugin has been blocked for your protection"?  Thanks!

Riju

Comment 11

[Riju Reghunath]

(In reply to Barry Marshall from comment #8)
> Presuming Mozilla could get a copy of the IBM JRE in question to test with,
> is there a mechanism that exists that is able to provide the type of block
> test that Riju talks about in Comment 3?  Or does that need a bug opened up
> for that?
> 
> Also, isn't this for all branches, not just 3.6?

Please let us know where we can upload IBM JDK for your testing? Also let us know platform and architecture details for which you need a IBM JDK build.

Comment 12

[Rick Alther]

(In reply to Riju Reghunath from comment #9)
> Kev Needham <[e-mail]> to Riju Reghunath
> 
> 
> > Many thanks Kev.
> >
> > May I request you to answer below questions, sorry if questions are
> > repetitive as we need these answer's before we provide an update to our
> > customer.
> >
> > 1) In future, the below Java plug-in warning message will no longer
> > displayed to Firefox customer's who all uses IBM JDK as their plug-in.
> 
> The block should be removed, yes, but confirmation that you're seeing 
> this would be great. There are also instructions on the addons blog for 
> testing the blocklist update at 
> http://blog.mozilla.com/addons/2012/04/04/update-on-java-blocklist/
My blocklist.xml is dated April 10 and I still see the same p80 block listed.

Comment 13

[Riju Reghunath]

We understand from original forum (https://bugzilla.mozilla.org/show_bug.cgi?id=739955) that the soft block is not yet functional for Linux OS. With blocklist.xml (p80) also we can see same regular expression logic for Windows and Linux OS, but file version for Linux Java plugin is totally different than expected Oracle File version on Windows(for e.g 6.0.310.5).

1)  Could you please confirm whether an actual blocking is implemented for Linux or not?
2) If not yet implemented / functional, what is next plan of Mozilla to get this done? Is there any alternative way identified for implementing a different soft block for Linux OS?

Many thanks in advance.

Comment 14

[Jorge Villalobos [:jorgev] (he/him)]

(In reply to Riju Reghunath from comment #13)
> 1)  Could you please confirm whether an actual blocking is implemented for
> Linux or not?

Yes, we're currently blocking libnpjp2.so

Comment 15

[Riju Reghunath]

(In reply to Jorge Villalobos [:jorgev] from comment #14)
> (In reply to Riju Reghunath from comment #13)
> > 1)  Could you please confirm whether an actual blocking is implemented for
> > Linux or not?
> 
> Yes, we're currently blocking libnpjp2.so


We see libnpjp2.so mentioned with blocklist.xml, but with our testing we came to know that blocking is not working for Linux irrespective level of Oracle Java6 update levels. The file version of libnpjp2.so is not same as mentioned with blocklist.xml. So, our question is, is there a plan to Mozilla to refix this for Linux OS? if yes, how Mozilla plan to achieve this?

Comment 16

[Jorge Villalobos [:jorgev] (he/him)]

(In reply to Riju Reghunath from comment #15)
> We see libnpjp2.so mentioned with blocklist.xml, but with our testing we
> came to know that blocking is not working for Linux irrespective level of
> Oracle Java6 update levels. The file version of libnpjp2.so is not same as
> mentioned with blocklist.xml. So, our question is, is there a plan to
> Mozilla to refix this for Linux OS? if yes, how Mozilla plan to achieve this?

We don't have a plan B for Linux at the moment. We know that the plugin doesn't report its version number correctly to Firefox, so our only other approach is to block by matching the description against a regular expression. This is what we're currently doing, and apparently that isn't working either.

Comment 17

[Riju Reghunath]

(In reply to Jorge Villalobos [:jorgev] from comment #16)
> (In reply to Riju Reghunath from comment #15)
> > We see libnpjp2.so mentioned with blocklist.xml, but with our testing we
> > came to know that blocking is not working for Linux irrespective level of
> > Oracle Java6 update levels. The file version of libnpjp2.so is not same as
> > mentioned with blocklist.xml. So, our question is, is there a plan to
> > Mozilla to refix this for Linux OS? if yes, how Mozilla plan to achieve this?
> 
> We don't have a plan B for Linux at the moment. We know that the plugin
> doesn't report its version number correctly to Firefox, so our only other
> approach is to block by matching the description against a regular
> expression. This is what we're currently doing, and apparently that isn't
> working either.

Thanks for providing these detail. It would be helpful, if Mozilla team can acknowledge IBM Java team well in advance if any future plan to block Java plug-ins with Linux platforms. This would help IBM Java team to act whether we providing a correct identifier or not.

Comment 18

[Jorge Villalobos [:jorgev] (he/him)]

We will keep that in mind, thanks.

Is there anything that needs to be done for this bug or should I just close it?

Comment 19

[Riju Reghunath]

Thanks.
Yes, we would like to have this bug open. We will be providing a IBM JRE version for Windows platforms (32 and 64 bit) with  file version identifier of Java plug-in having  CVE-2012-0507 fix. Once you receive this level,  please change your blockfile script to accommodate IBM plugin version separately.

Comment 20

[Jorge Villalobos [:jorgev] (he/him)]

If you are using the same file names and different version ranges, I don't think we can accommodate this request without putting users at risk.

Comment 21

[Rick Alther]

(In reply to Jorge Villalobos [:jorgev] from comment #20)
> If you are using the same file names and different version ranges, I don't
> think we can accommodate this request without putting users at risk.

Why not?  I would think you'd need to write a new plugin block rule for IBM Java.  It would match the filename npjp2/dll/libnpjp2.so, and check the description for 'IBM'.  If that passes it would then check the version in the Description string just like the Oracle block.

The Oracle block would have to be modified to only activate if the description string did not contain 'IBM'.  Otherwise it can remain the same.

Comment 22

[Jorge Villalobos [:jorgev] (he/him)]

Can you give me the exact description string of the fixed IBM plugin? I wasn't aware you used a different description string.

Comment 23

[Rick Alther]

Attachment: Screenshot showing patch IBM Java plugin details

A rule that can block plugins below this version might look like this:
<pluginItem blockId="pXX">
   <match name="name" exp="^IBM" />
   <match name="filename" exp="(npjp2\.dll)|(libnpjp2\.so)" />
   <versionRange minVersion="6.0.0.0" maxVersion="6.0.10.0" severity="1"></versionRange>
</pluginItem>

Because the proper version is not contained in the Description, separate rules would need to be written for Java 5 and 7 (unless you can add multiple <versionRange> tags).

The existing p80 rule would need to be updated to NOT catch the IBM plugin but only the Oracle plugin.

Comment 24

[Jorge Villalobos [:jorgev] (he/him)]

I added a RE name check for \(TM\) on the current blocklist entry. This should free the IBM versions from the block.

Now, do you need a separate block for the IBM version of the plugin as specified in comment #23, or is this something you prefer to manage yourselves?

Comment 25

[Rick Alther]

(In reply to Jorge Villalobos [:jorgev] from comment #24)
> I added a RE name check for \(TM\) on the current blocklist entry. This
> should free the IBM versions from the block.
> 
> Now, do you need a separate block for the IBM version of the plugin as
> specified in comment #23, or is this something you prefer to manage
> yourselves?

Jorge, the change your made which unblocks IBM Java is good enough.  No need to add the a specific block for our plugin as I described in comment #23.

When do you anticipate the new modified blocklist to go live?

Thanks,
- Rick

Comment 26

[Rick Alther]

I see the updated blocklist has already gone live.  Thanks Jorge!

Comment 27

[Jorge Villalobos [:jorgev] (he/him)]

Glad that worked. Calling this fixed per comment #25 and comment #26.