Closed Bug 663899 Opened 13 years ago Closed 13 years ago

.jar should not be openable on Mac or Linux, download only (CVE-2011-3666)

Categories

(Core Graveyard :: File Handling, defect)

x86
macOS
defect
Not set
critical

Tracking

(firefox5- wontfix, firefox6- wontfix, firefox7+ fixed, firefox8+ fixed, firefox9+ fixed, blocking2.0 -, status2.0 wontfix, blocking1.9.2 .23+)

VERIFIED FIXED
mozilla9
Tracking Status
firefox5 - wontfix
firefox6 - wontfix
firefox7 + fixed
firefox8 + fixed
firefox9 + fixed
blocking2.0 --- -
status2.0 --- wontfix
blocking1.9.2 --- .23+

People

(Reporter: dveditz, Assigned: espindola)

References

()

Details

(Keywords: qawanted, verified-aurora, verified-beta, Whiteboard: [sg:critical][qa-examined-192][qa!])

Attachments

(6 files, 1 obsolete file)

+++ This bug was initially created as a clone of Bug #662309 +++

On windows it was simple to make .jar executable in nsLocalFileWin and force users to download a .jar rather than letting them "open" it and run a privileged local Java Application. On Mac most files with the executable bit set do trigger the "save only" path, but something is special-casing .jar (noticing that the system has a handler for it) and letting it be opened anyway. I could not find any equivalent "blacklist" on Mac that .jar could be added to, and we desperately need one: just because the OS knows how to run a java archive (or other types) doesn't mean it's wise to do so from a web page.

Someone who knows mac will have to take this. The original bug on this was externally reported and the Windows variant is fixed in Fx5 and 3.6.18 -- this is important to fix soon.
> but something is special-casing .jar

Not at all.  It's just that it does not have the executable bit set...

The same issue probably arises with other filetypes on Mac and Linux if the default OS handler for the type can do dangerous things (and for non-executable types like Word documents with macros on Windows, for that matter!).
(In reply to comment #1)
> > but something is special-casing .jar
> 
> Not at all.  It's just that it does not have the executable bit set...
> 
> The same issue probably arises with other filetypes on Mac and Linux if the
> default OS handler for the type can do dangerous things (and for non-executable
> types like Word documents with macros on Windows, for that matter!).

So, should _we_ special case .jar files on Mac?
Keywords: verified1.9.2
We are willing to ship Firefox 5 with the incomplete stopgap.
> So, should _we_ special case .jar files on Mac?

Perhaps.  If so, also various other stuff too, right?  E.g. what's the (default?) OS helper app for .pl files?  .py files?  .sh files?  Other interesting things?
(In reply to comment #4)
> > So, should _we_ special case .jar files on Mac?
> 
> Perhaps.  If so, also various other stuff too, right?  E.g. what's the
> (default?) OS helper app for .pl files?  .py files?  .sh files?  Other
> interesting things?

That sounds like a catch-me-if-you-can game :/  Do we have a better way to recognize these types of files in general (not that I know of any)?
I'd really rather not have this assigned to me - perhaps Steven Michaud can look into it?
Assignee: joshmoz → smichaud
Is it merely as simple as, as in the Windows patch, having nsLocalFileUnix::IsExecutable return PR_FALSE for these and other files such as scripts? It seems like this would be useful for other Unices. If that seems an acceptable approach, I'll whip up something.
er, PR_TRUE even
> Is it merely as simple as, as in the Windows patch, having
> nsLocalFileUnix::IsExecutable return PR_FALSE for these and other
> files such as scripts? It seems like this would be useful for other
> Unices. If that seems an acceptable approach, I'll whip up
> something.

> er, PR_TRUE even

This sounds reasonable to me, at least as a stopgap.

I'll test other browsers' behavior with *.jar and *.py files (plus
other files that the OS supports on some level, but which we don't
want to run from the browser), and dig up what I can about how the OS
determines how these files should be handled.  But this will probably
take a while.
Note that whatever we do, we (presumably) need to ensure that WebStart applications still work properly.
Just now I've done some very basic testing (with various browsers on
OS X 10.5.8) with my TestJavaApp.jar testcase.

When you click on the file, FF 4.0.1 and a current nightly put up a
dialog asking whether to open the file (with JarLauncher) or save it
to disk.  Opening the file (with JarLauncher) is the default.

Safari automatically saves it to disk.

Chrome and Opera also put up dialogs asking the user to open or save
the file, but both of them default to saving it.
Attached patch WIP for feedback (obsolete) — Splinter Review
First pass for feedback (this builds, not tested). Steven, what do you think?
Attachment #541099 - Flags: feedback?(smichaud)
Comment on attachment 541099 [details] [diff] [review]
WIP for feedback

This looks fine to me, with the following caveats:

1) You don't need to include "app" in executableExts.

   Things that end in *.app are directory trees, not files -- they're
   application "bundles".

   I'm not sure if we ever download directory trees (as opposed to
   their individual contents).  If we do, it's probably best to call
   the nsILocalFileMac IsPackage() method to make sure we're not
   dealing with a "bundle" (application bundle or otherwise) -- which
   we'd presumably never want to "execute", only to "save".

2) We might need to add other extensions to executableExts, like "py".

I'm working to create a hello-world WebStart app and Python script to
test with.  This is just to start with -- we may also need other kinds
of testcases.

And by the way, a *.jar file isn't a "bundle" as that word is usually
used with respect to OS X -- it's basically a zip archive, which is a
single file.
Attachment #541099 - Flags: feedback?(smichaud) → feedback+
No, I'm aware that .app should be always a directory bundle, but I put that there because if it really is a file and it ends in .app, we should probably always treat it as hinky.

The other extensions I was thinking of: .py, .pl, .sh, .rb
Any others?

I'll run off a build and bang on it tonight and then make a reviewable patch (I'm in a conference call on the office PC right now).
> No, I'm aware that .app should be always a directory bundle, but I
> put that there because if it really is a file and it ends in .app,
> we should probably always treat it as hinky.

To keep our sanity, I think we should only put extensions in
executableExts that we *know* will cause trouble, and then only if
there isn't some other way to exclude them (such as using
nsILocalFileMac::IsPackage()).

> The other extensions I was thinking of: .py, .pl, .sh, .rb

What is .rb?

And once gain, I think we should only include extensions that we can
demonstrate (with a testcase) are "executable" when we ask the OS to
"run" files that have them.

> Any others?

.csh?  .pm?

Unless we limit ourselves to extensions that we know might get
"executed", the list might become almost endless.

As I said above, I think the approach you suggested in comment #7 is
at best a stopgap.  I'm going to try to find a way to make FF and/or
the OS no longer ever default to wanting to "run" an "executable" file
(as opposed to "saving" it).

I think it would be acceptable if the user were offered the choice of
running or saving a file, as long as the default was always to save
the file.  Especially since this is what Chrome and Opera do.  What do
people think?
> Simple Python script test case

Firefox doesn't default to "opening" this file, and doesn't even know
what app to "open" it with.  And I can't get Safari, Chrome or Python
to execute it, either.

So we might *not* need to include any script file extensions in
executableExts.
Comment on attachment 541209 [details]
Simple Python script test case

By the way, I copied this from http://www.neowin.net/forum/topic/706942-howto-program-using-python/.
(Following up comment #10)

> And I can't get Safari, Chrome or Python to execute it, either.

I meant Safari, Chrome or *Opera*.
(taking)

This is essentially the same patch, minus the .app. On testing, the helper dialogue for .jar comes up with Save File as the default, and if you try to double click it from the Downloads window, it correctly warns you the file is executable. Steven, are you okay with reviewing? Technically this isn't just Mac, but I can #ifdef it to just Mac if this is desirable. However, I suspect this is valuable for other platforms.
Assignee: smichaud → spectre
Attachment #541099 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #541270 - Flags: review?(smichaud)
Comment on attachment 541270 [details] [diff] [review]
Mark .jar and .air as executable regardless of execute bit

This looks fine to me.

I'm going to spend another few hours trying to find a more generic way
to fix this bug ... but I doubt that whatever I find (if anything)
will be better than your patch.  It really helps that we (apparently)
don't need to worry about executable scripts (more on this in a later
comment).

> Technically this isn't just Mac, but I can #ifdef it to just Mac if
> this is desirable. However, I suspect this is valuable for other
> platforms.

Testing on a couple of Linux distros (Ubuntu and Fedora), I found that
Firefox didn't want to execute my runnable jarfile testcase on either
of them.  So I was tempted to ask you to #ifdef this patch for the
Mac.

But your patch won't (I don't think) change Firefox's behavior on
either of these Linux distros, and (who knows) there might exist a
Linux equivalent of OS X's Jar Launcher, which (if installed) Firefox
might (by default) want to use to "open" a downloaded jarfile.

So I'm fine with having this patch effect any platform with a
Unix-like filesystem.  But let's keep an eye out for possible
problems.
Attachment #541270 - Flags: review?(smichaud) → review+
Comment on attachment 541270 [details] [diff] [review]
Mark .jar and .air as executable regardless of execute bit

Thanks for the review, Steven :)

I don't think there should be a problem with this approach for 3.6, but I'll try this tonight. Meanwhile requesting approvals for -aurora (7) and -beta (6), assuming it lands after the beta 5->6 transition on 7/5.
Attachment #541270 - Flags: approval-mozilla-beta?
Attachment #541270 - Flags: approval-mozilla-aurora?
Comment on attachment 541270 [details] [diff] [review]
Mark .jar and .air as executable regardless of execute bit

By the way, I think this should bake on the trunk for a while (a week?).  So it should land there as soon as possible.
Check-in needed, unless you're able to, Steven (I don't have access).
Keywords: checkin-needed
Landed on mozilla-inbound.
Keywords: checkin-needed
OS X makes executable scripts very difficult to run except from the
command line.  So, for that matter, do the Linux distros that I
tested.  So it's very unlikely that we'll have to worry about
executable scripts in the context of this bug.

I've posted a couple of testcases here (a Python script and a shell
script) and tested using Firefox or other browsers to download them --
I couldn't get Firefox (or any other browser) to execute either
script.

Both scripts (of course) run (and work correctly) from the command
line.  But double-clicking on the shell script loads it into TextEdit,
and double-clicking on the Python script runs a program called Build
Applet, which creates a double-clickable wrapper for the Python
script.

There's a wonderfully useful "Default Apps" pref panel that tells you
a lot about the information that Launch Services stores, and uses to
decide which apps to run in which circumstances
(http://www.rubicode.com/Software/RCDefaultApp/).  With it I couldn't
find a single script extension or mime type that was associated with a
program that could run it.  (Many script extensions or mime types are
simply absent from the LS database.  Others (like 'pl', 'rb' or 'tcl')
are associated with a text editor or an IDE (like XCode).)
On 1.9.2 the fix also performs as expected, but there are two different ::IsExecutable's, one for Solaris and BeOS, and one for everyone else. Do we want the change in both places or just in the everyone else category? (I imagine the latter.)
Merged from mozilla-inbound to mozilla-central.

http://hg.mozilla.org/mozilla-central/rev/83c0640ea8b1
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla7
Comment on attachment 541270 [details] [diff] [review]
Mark .jar and .air as executable regardless of execute bit

Please land this asap. Thanks.
Attachment #541270 - Flags: approval-mozilla-beta?
Attachment #541270 - Flags: approval-mozilla-aurora?
Attachment #541270 - Flags: approval-mozilla-aurora+
Comment on attachment 541270 [details] [diff] [review]
Mark .jar and .air as executable regardless of execute bit

Landed on aurora:
http://hg.mozilla.org/releases/mozilla-aurora/rev/210714b766cd
What's the call on comment 30?
Summary: .jar should not be openable on Mac, download only → .jar should not be openable on Mac or Linux, download only (CVE-2011-2372)
Marking fixed for branches where this was fixed!
(In reply to comment #30)
> On 1.9.2 the fix also performs as expected, but there are two different
> ::IsExecutable's, one for Solaris and BeOS, and one for everyone else. Do we
> want the change in both places or just in the everyone else category? (I
> imagine the latter.)

Everyone else is fine.
I'll generate a 1.9.2 patch for that code section as soon as I get my dev systems back online (house move this weekend and Time Warner sucks).
It actually transplanted successfully with a bit of context fuzz:

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/2bf4a50fa874

I didn't build locally so hopefully the transplant didn't bork anything....I'll watch tinderbox.
Attachment #541270 - Flags: approval1.9.2.20+
(In reply to Steven Michaud from comment #11)
> Created attachment 541078 [details]
> Simple runnable jar file to test with

Running this in 3.6.19 and 3.6.20 build 1 on OS X, I see no difference in behavior. Both of them attempt to "open" by Jar Launcher, rather than offering saving as the only option.

This doesn't strike me as "fixed" behavior unless I'm completely misunderstanding Dan's comments in comment 0.
blocking1.9.2: .20+ → .21+
Whiteboard: [sg:critical] → [sg:critical][qa-examined-192]
> Running this in 3.6.19 and 3.6.20 build 1 on OS X, I see no
> difference in behavior. Both of them attempt to "open" by Jar
> Launcher, rather than offering saving as the only option.

Does this happen with a clean profile?

I'll download 3.6.20 and see what happens to me.
Where is "3.6.20 build 1"?
Since this bug's fix was landed on the 1.9.2 branch on 2011-08-01, it is (of course) not in FF 3.6.19, which is dated 2011-07-07.
The patch isn't supposed to make saving the only option, just the default. I'm still completely hosed netwise at my house, but when I built a previous 1.9.2 with this, that's what it did for me.
(In reply to Steven Michaud from comment #41)
> Where is "3.6.20 build 1"?

ftp://ftp.mozilla.org/pub/firefox/nightly/3.6.20-candidates/build1/

This wasn't a completely clean profile. It had the Jar Launcher as the default option.
On a completely clean profile (using OS X 10.7), when I go to https://bugzilla.mozilla.org/attachment.cgi?id=541078 with Firefox 3.6.20 build 1, the default option is "Jar Launcher" there.
I see the same thing, testing with today's trunk nightly and a clean profile, also on OS X 10.7.

But if you do Save As even once with my TestJavaApp.jar file, all subsequent tests work properly -- you're prompted to save the file.  This is even if you don't ask the browser to "do this automatically from now on".

Sounds like we screwed up rather badly :-(

I'm in the midst of dealing with two other very urgent bugs (bug 668953 and bug 670842), and I *really* don't want to have to drop them for what might turn out to be a week, in order to fix this bug properly.

So I suggest we hold fixing this bug until FF 3.6.21.

I don't think we need to back out Cameron's patch, though.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
So this isn't really fixed for Firefox 6/7 or 1.9.2 then. 

We need to make sure not to disclose this accidentally until we can get a final fix.
> So this isn't really fixed for Firefox 6/7 or 1.9.2 then.

Apparently not ... though I haven't had a chance to do more than minimal testing.  The key is to always test with a clean profile.

Thanks for catching this, Al ... though it was a bit like a punch in the stomach :-(
(In reply to Al Billings [:abillings] from comment #47)
> So this isn't really fixed for Firefox 6/7 or 1.9.2 then. 

Do we have confirmation of that for Firefox 6/7? It's possible that the 1.9.2 patch alone was broken, and I don't see anyone mentioning tests on 6/7.
Can someone else please do those tests?
Oh. Bug 571193 didn't land on 1.9.2, so the patch would have only affected Linux there (and not Mac). Downside to blind transplants :(
(In reply to Gavin Sharp from comment #49)
> (In reply to Al Billings [:abillings] from comment #47)
> > So this isn't really fixed for Firefox 6/7 or 1.9.2 then. 
> 
> Do we have confirmation of that for Firefox 6/7? It's possible that the
> 1.9.2 patch alone was broken, and I don't see anyone mentioning tests on 6/7.

Well, Steven said he tested on "trunk" though I'm not sure what build he used.
Today's mozilla-central nightly:  firefox-2011-08-09-03-07-51-mozilla-central.
I'll look at this in more detail as soon as I can get Time Warner to actually do anything.
(Following up comment #50)

> (In reply to Al Billings [:abillings] from comment #47)
>> So this isn't really fixed for Firefox 6/7 or 1.9.2 then.
>
> Do we have confirmation of that for Firefox 6/7? It's possible that
> the 1.9.2 patch alone was broken, and I don't see anyone mentioning
> tests on 6/

> Can someone else please do those tests?

Seeing as I'm (for now) no longer in the middle of other things, and
nobody else has done them, I've now done them myself.

I've tested FF 3.6b5, yesterday's mozilla-central nightly (again), and
today's aurora nightly -- this time all on OS X 10.6.8.  I gave myself
a clean profile before the first of these tests.  In all of them this
bug still happens (testing with my "simple runnable jar file" testcase
(attachment 541078 [details])).
(In reply to Al Billings [:abillings] from comment #47)
> So this isn't really fixed for Firefox 6/7 or 1.9.2 then. 
> 
> We need to make sure not to disclose this accidentally until we can get a
> final fix.

We need to unset the status flags then because release triage and announcement decisions are based on them.

(In reply to Cameron Kaiser from comment #43)
> The patch isn't supposed to make saving the only option, just the default.

What would it take to make saving the only option? That's what happens for "unsafe/executable" types on windows and that's what we want to happen on other platforms. See "not openable....download only" in bug summary!
Not sure where we are in getting this fixed. It seems a bit stalled. Steven are you the right guy to help with this?
Here's another thought. Have HelperApps.updateTypeInfo in toolkit/mozapps/downloads/content/helperApps.js willfully "lie": if the file is in the list of proscribed extensions, either by using IsExecutable() in NSPR or having its own list, then set entry.appPath to "" and entry.saveToDisk to true. That should only present one option, if I understand the code correctly.
> Steven are you the right guy to help with this?

I *could* help with this -- I'm very good at figuring out obscure
problems, especially on the Mac.  But I'm not currently very familiar
with the code in which changes would probably need to be made.	So
it'd take me a while to catch up (a week sounds about right), and I've
got *lots* of (probably) more urgent bugs to deal with -- mostly
having to do with OS X 10.7.

So if you can find someone else	to shepherd this bug, I'd really
appreciate it :-)

Cameron, unfortunately I can't really respond to your suggestion
without spending a lot more time digging in to this bug.
JP, can you help us find an owner for this bug?
After reviewing this and running some simple Mac tests, is there a reason we can't use the Windows type approach for this right now based on extensions?

Rafael may have some time to look too.
Ok, Rafael, can you look into this? We need traction on this very soon, so if you can't, please speak up.
Assignee: spectre → respindola
(In reply to Johnny Stenback (:jst, jst@mozilla.com) from comment #62)
> Ok, Rafael, can you look into this? We need traction on this very soon, so
> if you can't, please speak up.

I have some other bugs on my plate (674647, 678558, 673017, 682066), but since this is more important I will try to look at it tonight when I get home.
The reason the current code is not working is that nsLocalFile::IsExecutable is being passed a file named "foo.jar.part".

The windows code creates a dummy file, that is really ugly, but I will probably piggyback on it for now and clean it up afterwards.
Comment on attachment 555937 [details] [diff] [review]
use a dummy file everywhere.

I need to test this on multiple platforms before I can approve it.  I'm about to start some tryserver builds.
Comment on attachment 555937 [details] [diff] [review]
use a dummy file everywhere.

This looks fine to me.

And I got the test results I expected:  Attempts to download my simple
runnable jar testcase (attachment 541078 [details]) now work the same on OS X
and Linux as they do on Windows -- you have no option to run the file,
only to download it.  (And by the way, I made sure to always test with
a clean profile.)

Sorry I missed that nsLocalFile::IsExecutable() was being called with
[xxxx].jar.part :-(

Perhaps the helper app (and local file) code can be cleaned up at some
point.  But this looks like a good interim solution.  

Though (of course) I still don't know much about this code, so there
might be something else	that I missed.
Attachment #555937 - Flags: review?(smichaud) → review+
I should have noticed that myself. Sorry. :(
Pushed to
http://hg.mozilla.org/integration/mozilla-inbound/rev/4a31be812223

Who is responsible for merging this to the old releases? If the answer is "I", is there any docs on the process?
> Who is responsible for merging this to the old releases?

As the bug's assignee, I suppose you are :-)

> If the answer is "I", is there any docs on the process?

I don't know of any.  But first things first:  Before landing you need to seek approval.  I'd suggest asking for approval at least for aurora and the 1.9.2 branch.

And maybe also for beta.  Dan, Sheila, JP:  What do you think?
Can we get this verified now that the patch has landed? Given that we fixed this w/o actually fixing it once, I'd like to be certain that it's fixed for real before we take this on branches etc.
Keywords: qawanted
 > I don't know of any.  But first things first:  Before landing you need to
> seek approval.  I'd suggest asking for approval at least for aurora and the
> 1.9.2 branch.
> 
> And maybe also for beta.  Dan, Sheila, JP:  What do you think?

ping? Is there another process for asking for approval?
Comment on attachment 555937 [details] [diff] [review]
use a dummy file everywhere.

You ask for approval like so.

But (from comment #72) it sounds like approval won't be granted for any of the branches before someone from QA verifies that the bug is actually fixed.
Attachment #555937 - Flags: approval-mozilla-aurora?
(In reply to Johnny Stenback (:jst, jst@mozilla.com) from comment #72)
> Can we get this verified now that the patch has landed? Given that we fixed
> this w/o actually fixing it once, I'd like to be certain that it's fixed for
> real before we take this on branches etc.

Is there anything I need to do (other than the bug flag you added)?
Attachment #555937 - Flags: approval1.9.2.23?
Attachment #555937 - Flags: approval-mozilla-beta?
I can verify fixed using Steven's simple testcase (https://bugzilla.mozilla.org/attachment.cgi?id=541078) using:

Mozilla/5.0 (Windows NT 5.1; rv:9.0a1) Gecko/20110908 Firefox/9.0a1 and Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0a1) Gecko/20110908 Firefox/9.0a1.

I will verify using Linux in the lab before marking this for final verification.
Verified fixed on Linux using Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0a1) Gecko/20110908 Firefox/9.0a1. I also checked the latest nightly on Mac 10.7 and it looks good as well. I tested with a clean profile in each instance and confirmed that you only have the option to download the file and not run it (that option is greyed out in Steven's test case)
Comment on attachment 555937 [details] [diff] [review]
use a dummy file everywhere.

Approved for aurora and beta, and JP will track that this gets verified etc.
Attachment #555937 - Flags: approval-mozilla-beta?
Attachment #555937 - Flags: approval-mozilla-beta+
Attachment #555937 - Flags: approval-mozilla-aurora?
Attachment #555937 - Flags: approval-mozilla-aurora+
Comment on attachment 555937 [details] [diff] [review]
use a dummy file everywhere.

Please land this on releases/mozilla-1.9.2
Attachment #555937 - Flags: approval1.9.2.23? → approval1.9.2.23+
QA tracking; will need verification on Aurora, Beta, and 1.9.2 using the testcases attached to this bug.
Whiteboard: [sg:critical][qa-examined-192] → [sg:critical][qa-examined-192][qa+]
This is fixed on trunk now too, right? If so, can we close this bug by now?
I think we can close it yes, but I am not sure what is normally the protocol with security bugs.
Depends on: 689195
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Group: core-security
I have verified this using the first test from the attachements and the option to open the file is greyed out on:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20100101 Firefox/9.0 beta 2
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a2) Gecko/20111121 Firefox/10.0a2
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0a1) Gecko/20111121 Firefox/11.0a1

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20100101 Firefox/9.0 beta 2
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0a2) Gecko/20111121 Firefox/10.0a2
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0a1) Gecko/20111121 Firefox/11.0a1

I have also tested this on Firefox 1.9.2 and the "open file" option isn't greyed out on:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.24) Gecko/20111103 Firefox/3.6.24
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.2.24) Gecko/20111031 Firefox/3.6.24

This is intended? Can the resolution be changed to Verified?
I believe so, Vlad.
Status: RESOLVED → VERIFIED
Whiteboard: [sg:critical][qa-examined-192][qa+] → [sg:critical][qa-examined-192][qa!]
Testing with my "simple runnable jar file" testcase a clean profile in FF 3.6.24 (on OS X 10.7.2), this bug *isn't* fixed -- FF 3.6.24 still defaults to running the jar file in JarLauncher.

Sigh :-(

Also, this bug is only fixed in FF 7.0 and up -- not in FF 5.0.1 or 6.0.2.
> Also, this bug is only fixed in FF 7.0 and up -- not in FF 5.0.1 or 6.0.2.

Oops, misread our confusing user-agent strings.  Now I see that Vlad only tested on 9.0 beta2 and up.
(In reply to Steven Michaud from comment #87)
> Testing with my "simple runnable jar file" testcase a clean profile in FF
> 3.6.24 (on OS X 10.7.2), this bug *isn't* fixed -- FF 3.6.24 still defaults
> to running the jar file in JarLauncher.
Should this bug be cloned so the patch can be backported to 1.9.2?

> Also, this bug is only fixed in FF 7.0 and up -- not in FF 5.0.1 or 6.0.2.
Firefox 9.0 is the point-release for all previous versions.
> Should this bug be cloned so the patch can be backported to 1.9.2?

It *has* been backported to the 1.9.2 branch (see comment #81).  It just doesn't work there, apparently.

I suppose it makes sense to open a new bug on that, though.
Blocks: 704622
Summary: .jar should not be openable on Mac or Linux, download only (CVE-2011-2372) → .jar should not be openable on Mac or Linux, download only (CVE-2011-3666)
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.