Bugzilla

Updated

•

7 years ago

CC: rijureghunath

Comment 2

•

7 years ago

From:	Kev Needham <kev@mozilla.com>
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

•

7 years ago

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

•

7 years ago

Kev Needham <kev@mozilla.com> 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

•

7 years ago

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

•

7 years ago

Kev Needham <kev@mozilla.com> 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

•

7 years ago

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)?

Barry Marshall

Comment 8

•

7 years ago

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

•

7 years ago

Kev Needham <kev@mozilla.com> 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

•

7 years ago

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

•

7 years ago

(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

•

7 years ago

(In reply to Riju Reghunath from comment #9)
> Kev Needham <kev@mozilla.com> 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.

John Walicki

Updated

•

7 years ago

CC: walicki

Comment 13

•

7 years ago

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.

Scoobidiver (away)

Updated

•

7 years ago

Component: Untriaged → Blocklisting

Product: Firefox → addons.mozilla.org

QA Contact: untriaged → blocklisting

Version: 3.6 Branch → unspecified

Comment 14

•

7 years ago

(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

•

7 years ago

(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?

Fred Wenzel [:wenzel]

Updated

•

7 years ago

Summary: Incorrect FireFox error message while blocking IBM Java Plug-in → Incorrect Firefox error message while blocking IBM Java Plug-in

Comment 16

•

7 years ago

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

Scoobidiver (away)

Updated

•

7 years ago

Status: UNCONFIRMED → NEW

Ever confirmed: true

Comment 17

•

7 years ago

(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

•

7 years ago

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

•

7 years ago

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

•

7 years ago

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

•

7 years ago

(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

•

7 years ago

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

•

7 years ago

Created attachment 619255 [details]
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

•

7 years ago

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

•

7 years ago

(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

•

7 years ago

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