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

VERIFIED FIXED

Status

Core Graveyard
File Handling
--
critical
VERIFIED FIXED
6 years ago
10 months ago

People

(Reporter: dveditz, Assigned: espindola)

Tracking

(4 keywords)

1.9.2 Branch
x86
Mac OS X
qawanted, verified-aurora, verified-beta, verified1.9.2
Dependency tree / graph

Firefox Tracking Flags

(firefox8+ fixed, firefox9+ fixed, firefox10+ fixed, blocking1.9.2 .25+, status1.9.2 .25-fixed)

Details

(Whiteboard: [sg:critical][qa!], URL)

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
+++ This bug was initially created as a clone of Bug #663899 +++

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

A patch was landed for this in 1.9.23, but it did not fix the problem on the 1.9.2 branch. See bug 663899 comment 85
The patch that landed just used the same code that windows was using before.
Is the issues fixed on windows on 1.9.2?
(Reporter)

Updated

6 years ago
Assignee: nobody → respindola
(Reporter)

Comment 2

6 years ago
According to bug 662309 comment 12 this was verified in 1.9.2 on Windows
(Reporter)

Updated

6 years ago
blocking1.9.2: .23+ → .25+
status-firefox10: --- → fixed
tracking-firefox10: --- → +
what mozconfig have you used? I just started a build with

ac_add_options --enable-application=browser
ac_add_options --enable-update-channel=release
ac_add_options --enable-update-packaging
ac_add_options --enable-tests
ac_add_options --enable-official-branding

export MOZILLA_OFFICIAL=1

export MOZ_TELEMETRY_REPORTING=1
> what mozconfig have you used?

Who are you asking? :-)

The mozconfigs used in "official" distros (nightlies and releases) can be found in their build logs.
I could not find a build log for this one. I think 1.9.2 is build so infrequently that the last one is not available anymore.

I just found out that it fails to build in 64 bits, so what I am trying now is


export CC="/usr/bin/gcc-4.2 -arch i386"
export CXX="/usr/bin/g++-4.2 -arch i386"

ac_add_options --enable-application=browser
ac_add_options --enable-update-channel=release
ac_add_options --enable-update-packaging
ac_add_options --enable-tests
ac_add_options --enable-official-branding

export MOZILLA_OFFICIAL=1

export MOZ_TELEMETRY_REPORTING=1

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-test
mk_add_options MOZ_MAKE_FLAGS="-j4"
> I just found out that it fails to build in 64 bits

1.9.2 is 32-bit only (on OS X).

Here's the mozconfig I normally use to do 32-bit 1.9.2-branch builds on SnowLeopard.  On 64-bit SnowLeopard (presumably what you're running) it needs to be a cross-compile.

export CFLAGS="-g -gfull"
export CXXFLAGS="-g -gfull"
. $topsrcdir/browser/config/mozconfig
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-firefox
mk_add_options MOZ_MAKE_FLAGS=-j4
mk_add_options AUTOCONF=autoconf213
ac_add_options --disable-optimize
ac_add_options --enable-tests
ac_add_options --enable-cpp-rtti
ac_add_options --enable-logrefcnt
ac_add_options --disable-strip
ac_add_options --disable-install-strip
ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.5.sdk

CC="gcc-4.2 -arch i386"
CXX="g++-4.2 -arch i386"
ac_add_options --target=i386-apple-darwin8.0.0
ac_add_options --enable-macos-target=10.5
# bug 491774. crashreporter won't build in cross compile
ac_add_options --disable-crashreporter

HOST_CC="gcc-4.2"
HOST_CXX="g++-4.2"
RANLIB=ranlib
AR=ar
AS=$CC
LD=ld
STRIP="strip -x -S"
CROSS_COMPILE=1
> I think 1.9.2 is build so infrequently that the last one is not available anymore.

I just confirmed this :-(
NP, I was able to reproduce the bug. Trying to figure out what is going on in 1.9.2
Created attachment 579157 [details] [diff] [review]
Copy and paste the logic from nsLocalFileUnix.cpp to nsLocalFileOSX.mm

The problem was that in 1.9.2 nsLocalFileOSX.mm was not yet merged into nsLocalFileUnix.cpp .
Attachment #579157 - Flags: approval1.9.2.25?
Attachment #579157 - Flags: review?(smichaud)
Comment on attachment 579157 [details] [diff] [review]
Copy and paste the logic from nsLocalFileUnix.cpp to nsLocalFileOSX.mm

> Copy and paste the logic from nsLocalFileUnix.cpp to
> nsLocalFileOSX.mm

You copied code from nsLocalFileUnix.cpp *on the trunk* to
nsLocalFileOSX.mm *on the 1.9.2 branch*.  But shouldn't you also copy
this code to nsLocalFile::IsExecutable() in nsLocalFileUnix.cpp	*on
the 1.9.2 branch*?
Comment on attachment 579157 [details] [diff] [review]
Copy and paste the logic from nsLocalFileUnix.cpp to nsLocalFileOSX.mm

This patch fixes this bug on OS X (testing on OS X 10.6.8 with my "simple runnable jar file" from bug 663899 - attachment 541078 [details]).

I'll see if I can manage to test a recent 1.9.2-branch nightly on Linux.
> I'll see if I can manage to test a recent 1.9.2-branch nightly on Linux.

I haven't been able to test on a Linux installation that has a default app for jar files (as Jar Launcher is on OS X).
(Reporter)

Comment 13

6 years ago
Code-freeze for 1.9.2.25 is Friday, please make sure this is done in time to get approval to land (e.g. before we leave for the day). Time is tight, ping us in IRC for approval.
(Following up comment #10)

Oops, I was looking at the wrong copy of nsLocalFile::IsExecutable() in nsLocalFileUnix.cpp -- the one for Beos and Solaris.  The one for everything else *does* already have the extension checking code.

Sorry for the confusion :-(
Attachment #579157 - Flags: review?(smichaud) → review+
Comment on attachment 579157 [details] [diff] [review]
Copy and paste the logic from nsLocalFileUnix.cpp to nsLocalFileOSX.mm

[Triage Comment]
Approving for 1.9.2.25.

Al - can you make sure to test this with Win/Mac and Linux? smichaud hasn't had access to a Linux setup to test. Thanks!
Attachment #579157 - Flags: approval1.9.2.25? → approval1.9.2.25+
(Reporter)

Comment 16

6 years ago
Comment on attachment 579157 [details] [diff] [review]
Copy and paste the logic from nsLocalFileUnix.cpp to nsLocalFileOSX.mm

Approved for 1.9.2.25, a=dveditz
https://tbpl.mozilla.org/?tree=Firefox3.6&rev=eefedeec832e
(Reporter)

Updated

6 years ago
status1.9.2: --- → .25-fixed
(Reporter)

Comment 18

6 years ago
Since this is a branch-only bug it can be marked FIXED now, right?
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
> Since this is a branch-only bug it can be marked FIXED now, right?

I think so.
Whiteboard: [sg:critical] → [sg:critical]qa
Whiteboard: [sg:critical]qa → [sg:critical]
Verified with https://bugzilla.mozilla.org/attachment.cgi?id=541078 with latest 1.9.2.25pre build.

On OS X 10.7, option to open jar file is grayed out.

On Ubuntu 11.10, option to open a jar file is grayed out.

On Win XP, it just prompts you to save with no option to open.

This is all with the 12/9/2011 1.9.2 build (the latest nightly).

Verified for 1.9.2.
Keywords: verified1.9.2
Whiteboard: [sg:critical] → [sg:critical][qa+]
Can this be marked verified? I noticed all verified* keywords were already set...
Whiteboard: [sg:critical][qa+] → [sg:critical][qa?]
Based on conversation with Dan on IRC we need not retest this on Firefox 9, 10, or 11.

Marking this bug VERIFIED. If this is in error and there is something left for QA to test, please let us know.
Status: RESOLVED → VERIFIED
Whiteboard: [sg:critical][qa?] → [sg:critical][qa!]
Checked using https://bugzilla.mozilla.org/attachment.cgi?id=541078 on OS X 10.7 with Firefox 9, Beta 6 build. The open option is grayed as expected.
(Reporter)

Updated

5 years ago
Summary: [1.9.2] .jar should not be openable on Mac or Linux, download only (CVE-2011-2372) → [1.9.2] .jar should not be openable on Mac or Linux, download only (CVE-2011-3666)
(Reporter)

Updated

5 years ago
Group: core-security
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.