Closed Bug 1211262 (CVE-2015-7194) Opened 9 years ago Closed 9 years ago

Arbitrary memory access in libjar (libxul)

Categories

(Core :: Networking: JAR, defect)

Product:
Core
Component:
Networking: JAR
Version:
41 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla44
Tracking Flags:
Tracking Status
firefox41 --- wontfix
firefox42 + fixed
firefox43 + fixed
firefox44 + verified
firefox-esr38 42+ fixed

People

(Reporter: gustavo.grieco, Assigned: bugzilla)

Details

(Keywords: csectype-bounds, reporter-external, sec-high, Whiteboard: [adv-main42+][adv-esr38.4+])

Attachments

(5 files, 3 obsolete files)

test.xpi
121 bytes, application/x-xpinstall
Details
test_open_xpi.js
1.06 KB, application/javascript
Details
Patch (r3)
3.57 KB, patch
bugzilla
: review+
abillings
: sec-approval+
Details | Diff | Splinter Review
Patch containing fix only (r2)
1.10 KB, patch
bugzilla
: review+
lizzard
: approval-mozilla-aurora+
lizzard
: approval-mozilla-beta+
ritu
: approval-mozilla-esr38+
Details | Diff | Splinter Review
Patch containing fix only (r3)
1.10 KB, patch
bugzilla
: review+
Details | Diff | Splinter Review
Attached file test.xpi —
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0 Build ID: 20150918100310 Steps to reproduce: An arbitrary memory access was found in libjar using a specially crafted zip. It was tested in the libjar code shipped in Firefox 41 as well as Firefox 44.0a1. To reproduce this issue, find attached a test case (causing reading outside the buffers bounds in heap or stack randomly) and a JavaScript file to trigger this vulnerability in xpcshell (available in the xulrunner-sdk). This particular xpi file is rejected by Firefox if you try to install them as extension, but we believe it could be modified to have a valid install.rdf file and cause the crash in parsing of an extension to install. At this point, i think it is quite important to know if this issue can be easily exploited remotely without user intervention. Actual results: The report of a debugger (x86) is available here: $ LD_LIBRARY_PATH=".:./plugins:." gdb --args ./xpcshell test_open_xpi.js $(pwd)/test.xpi Program received signal SIGSEGV, Segmentation fault. 0xb4429161 in nsJARInputStream::Read(char*, unsigned int, unsigned int*) () from ./libxul.so (gdb) bt #0 0xb4429161 in nsJARInputStream::Read(char*, unsigned int, unsigned int*) () from ./libxul.so #1 0xb3fb3cca in nsScriptableInputStream::ReadHelper(char*, unsigned int) () from ./libxul.so #2 0xb3fb3dee in nsScriptableInputStream::Read(unsigned int, char**) () from ./libxul.so #3 0xb3fcf790 in NS_InvokeByIndex () from ./libxul.so #4 0xb440bab9 in XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) () from ./libxul.so #5 0xb440ea7d in XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) () from ./libxul.so #6 0xb5dfec24 in js::Invoke(JSContext*, JS::CallArgs const&, js::MaybeConstruct) () from ./libxul.so #7 0xb5dfa298 in Interpret(JSContext*, js::RunState&) () from ./libxul.so #8 0xb5dfe675 in js::RunScript(JSContext*, js::RunState&) () from ./libxul.so #9 0xb5dfe83a in js::ExecuteKernel(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value const&, JS::Value const&, js::ExecuteType, js::AbstractFramePtr, JS::Value*) () from ./libxul.so #10 0xb5dfe9b1 in js::Execute(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value*) () from ./libxul.so #11 0xb613e318 in ExecuteScript(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSScript*>, JS::Value*) () from ./libxul.so #12 0xb613e691 in JS_ExecuteScript(JSContext*, JS::Handle<JSScript*>, JS::MutableHandle<JS::Value>) () from ./libxul.so #13 0xb4404ebb in ProcessFile(mozilla::dom::AutoJSAPI&, char const*, _IO_FILE*, bool) () from ./libxul.so #14 0xb440529f in Process(mozilla::dom::AutoJSAPI&, char const*, bool) () from ./libxul.so #15 0xb440899b in XRE_XPCShellMain () from ./libxul.so #16 0x0804c42d in main (argc=4, argv=0xbffffb24, envp=0xbffffb38) at /builds/slave/m-cen-lx-000000000000000000000/build/src/js/xpconnect/shell/xpcshell.cpp:54 (gdb) x/i $eip => 0xb4429161 <_ZN16nsJARInputStream4ReadEPcjPj+187>: rep movsb %ds:(%esi),%es:(%edi) (gdb) info registers eax 0x2000004 33554436 ecx 0x1fde028 33415208 edx 0xaced5200 -1393733120 ebx 0xb7e4928c -1209757044 esp 0xbfffdc00 0xbfffdc00 ebp 0xbfffdc18 0xbfffdc18 esi 0xafa9a000 -1347837952 edi 0xa6821fdc -1501421604 eip 0xb4429161 0xb4429161 <nsJARInputStream::Read(char*, unsigned int, unsigned int*)+187> eflags 0x210286 [ PF SF IF RF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 and the report of Address Sanitizer (x86_64) is here: ==8811==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f3cd3729000 at pc 0x460117 bp 0x7fff821757d0 sp 0x7fff82174f90 READ of size 33554436 at 0x7f3cd3729000 thread T0 #0 0x460116 (/home/g/Apps/firefox-asan/firefox/xpcshell+0x460116) #1 0x7f3ce83a646d (libxul.so+0x333a46d) #2 0x7f3ce71a657e (libxul.so+0x213a57e) #3 0x7f3ce71a6381 (libxul.so+0x213a381) #4 0x7f3ce721a704 (libxul.so+0x21ae704) #5 0x7f3ce8328571 (libxul.so+0x32bc571) #6 0x7f3ce8327f7f (libxul.so+0x32bbf7f) #7 0x7f3ce832be9b (libxul.so+0x32bfe9b) #8 0x7f3cee569ad2 (libxul.so+0x94fdad2) #9 0x7f3cee56904c (libxul.so+0x94fd04c) #10 0x7f3cee55b0e9 (libxul.so+0x94ef0e9) #11 0x7f3cee548e50 (libxul.so+0x94dce50) #12 0x7f3cee56bbb2 (libxul.so+0x94ffbb2) #13 0x7f3cee56c83d (libxul.so+0x950083d) #14 0x7f3ceee6a06c (libxul.so+0x9dfe06c) #15 0x7f3ceee69e04 (libxul.so+0x9dfde04) #16 0x7f3ce8366b74 (libxul.so+0x32fab74) #17 0x7f3ce8366e13 (libxul.so+0x32fae13) #18 0x7f3ce830792f (libxul.so+0x329b92f) #19 0x7f3ce8305049 (libxul.so+0x3299049) #20 0x48a94f (/home/g/Apps/firefox-asan/firefox/xpcshell+0x48a94f) #21 0x7f3ce19c9ec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4) #22 0x48a6cc (/home/g/Apps/firefox-asan/firefox/xpcshell+0x48a6cc) 0x7f3cd3729000 is located 6144 bytes to the left of 167422-byte region [0x7f3cd372a800,0x7f3cd37535fe) freed by thread T0 here: #0 0x472ae1 (/home/g/Apps/firefox-asan/firefox/xpcshell+0x472ae1) #1 0x7f3cee193c30 (libxul.so+0x9127c30) #2 0x7f3cee66e9d3 (libxul.so+0x96029d3) #3 0x7f3ceee42a88 (libxul.so+0x9dd6a88) #4 0x7f3ce82b34c0 (libxul.so+0x32474c0) #5 0x7f3ce83445b3 (libxul.so+0x32d85b3) #6 0x7f3ce82d9958 (libxul.so+0x326d958) #7 0x7f3cec4750b4 (libxul.so+0x74090b4) #8 0x7f3ce71c5c8c (libxul.so+0x2159c8c) #9 0x7f3ce71c6bdd (libxul.so+0x215abdd) #10 0x7f3ce71c7a81 (libxul.so+0x215ba81) #11 0x7f3ce71c1226 (libxul.so+0x2155226) #12 0x7f3ce72690c4 (libxul.so+0x21fd0c4) #13 0x7f3ce724e0a4 (libxul.so+0x21e20a4) #14 0x7f3ce7240ae9 (libxul.so+0x21d4ae9) #15 0x7f3ce8304514 (libxul.so+0x3298514) #16 0x48a94f (/home/g/Apps/firefox-asan/firefox/xpcshell+0x48a94f) #17 0x7f3ce19c9ec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4) previously allocated by thread T0 here: #0 0x472ce1 (/home/g/Apps/firefox-asan/firefox/xpcshell+0x472ce1) #1 0x7f3cee0b8d47 (libxul.so+0x904cd47) #2 0x7f3cee0b5d75 (libxul.so+0x9049d75) #3 0x7f3cee66e8bd (libxul.so+0x96028bd) #4 0x7f3ceee42a88 (libxul.so+0x9dd6a88) #5 0x7f3ce82b34c0 (libxul.so+0x32474c0) #6 0x7f3ce83445b3 (libxul.so+0x32d85b3) #7 0x7f3ce82d9958 (libxul.so+0x326d958) #8 0x7f3cec4750b4 (libxul.so+0x74090b4) #9 0x7f3ce71c5c8c (libxul.so+0x2159c8c) #10 0x7f3ce71c6bdd (libxul.so+0x215abdd) #11 0x7f3ce71c7a81 (libxul.so+0x215ba81) #12 0x7f3ce71c1226 (libxul.so+0x2155226) #13 0x7f3ce72690c4 (libxul.so+0x21fd0c4) #14 0x7f3ce724e0a4 (libxul.so+0x21e20a4) #15 0x7f3ce7240ae9 (libxul.so+0x21d4ae9) #16 0x7f3ce8304514 (libxul.so+0x3298514) #17 0x48a94f (/home/g/Apps/firefox-asan/firefox/xpcshell+0x48a94f) #18 0x7f3ce19c9ec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4) SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 ?? Shadow bytes around the buggy address: 0x0fe81a6dd1b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe81a6dd1c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe81a6dd1d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe81a6dd1e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe81a6dd1f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0fe81a6dd200:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0fe81a6dd210: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0fe81a6dd220: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0fe81a6dd230: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0fe81a6dd240: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0fe81a6dd250: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd and here: ==8782==ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7fbb49f18a20 at pc 0x460117 bp 0x7fff6f1cbb70 sp 0x7fff6f1cb330 READ of size 33554436 at 0x7fbb49f18a20 thread T0 #0 0x460116 (/home/g/Apps/firefox-asan/firefox/xpcshell+0x460116) #1 0x7fbb5e95b46d (libxul.so+0x333a46d) #2 0x7fbb5d75b57e (libxul.so+0x213a57e) #3 0x7fbb5d75b381 (libxul.so+0x213a381) #4 0x7fbb5d7cf704 (libxul.so+0x21ae704) #5 0x7fbb5e8dd571 (libxul.so+0x32bc571) #6 0x7fbb5e8dcf7f (libxul.so+0x32bbf7f) #7 0x7fbb5e8e0e9b (libxul.so+0x32bfe9b) #8 0x7fbb64b1ead2 (libxul.so+0x94fdad2) #9 0x7fbb64b1e04c (libxul.so+0x94fd04c) #10 0x7fbb64b100e9 (libxul.so+0x94ef0e9) #11 0x7fbb64afde50 (libxul.so+0x94dce50) #12 0x7fbb64b20bb2 (libxul.so+0x94ffbb2) #13 0x7fbb64b2183d (libxul.so+0x950083d) #14 0x7fbb6541f06c (libxul.so+0x9dfe06c) #15 0x7fbb6541ee04 (libxul.so+0x9dfde04) #16 0x7fbb5e91bb74 (libxul.so+0x32fab74) #17 0x7fbb5e91be13 (libxul.so+0x32fae13) #18 0x7fbb5e8bc92f (libxul.so+0x329b92f) #19 0x7fbb5e8ba049 (libxul.so+0x3299049) #20 0x48a94f (/home/g/Apps/firefox-asan/firefox/xpcshell+0x48a94f) #21 0x7fbb57f7eec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4) #22 0x48a6cc (/home/g/Apps/firefox-asan/firefox/xpcshell+0x48a6cc) Address 0x7fbb49f18a20 is located in stack of thread T11 (JS Helper) at offset 0 in frame #0 0x7fbb64af130f (libxul.so+0x94d030f) This frame has 2 object(s): [32, 36) 'status' <== Memory access at offset 0 partially underflows this variable [48, 52) '' <== Memory access at offset 0 partially underflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) Thread T11 (JS Helper) created by T0 here: #0 0x45f555 (/home/g/Apps/firefox-asan/firefox/xpcshell+0x45f555) #1 0x7fbb6ad15c14 (libnspr4.so+0x71c14) #2 0x7fbb6ad1572a (libnspr4.so+0x7172a) #3 0x7fbb64aefa7b (libxul.so+0x94cea7b) #4 0x7fbb64b83b88 (libxul.so+0x9562b88) #5 0x7fbb653f7170 (libxul.so+0x9dd6170) #6 0x7fbb5d68696b (libxul.so+0x206596b) #7 0x7fbb5e885761 (libxul.so+0x3264761) #8 0x7fbb5e889355 (libxul.so+0x3268355) #9 0x7fbb5e8f91ef (libxul.so+0x32d81ef) #10 0x7fbb5e8f94da (libxul.so+0x32d84da) #11 0x7fbb5e88e958 (libxul.so+0x326d958) #12 0x7fbb62a2a0b4 (libxul.so+0x74090b4) #13 0x7fbb5d77ac8c (libxul.so+0x2159c8c) #14 0x7fbb5d77bbdd (libxul.so+0x215abdd) #15 0x7fbb5d77ca81 (libxul.so+0x215ba81) #16 0x7fbb5d776226 (libxul.so+0x2155226) #17 0x7fbb5d81e0c4 (libxul.so+0x21fd0c4) #18 0x7fbb5d8030a4 (libxul.so+0x21e20a4) #19 0x7fbb5d7f5ae9 (libxul.so+0x21d4ae9) #20 0x7fbb5e8b9514 (libxul.so+0x3298514) #21 0x48a94f (/home/g/Apps/firefox-asan/firefox/xpcshell+0x48a94f) #22 0x7fbb57f7eec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4) SUMMARY: AddressSanitizer: stack-buffer-underflow ??:0 ?? Shadow bytes around the buggy address: 0x0ff7e93db0f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ff7e93db100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ff7e93db110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ff7e93db120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ff7e93db130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0ff7e93db140: 00 00 00 00[f1]f1 f1 f1 04 f2 04 f3 00 00 00 00 0x0ff7e93db150: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 0x0ff7e93db160: 00 f2 f2 f2 01 f2 00 f3 f3 f3 f3 f3 00 00 00 00 0x0ff7e93db170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ff7e93db180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ff7e93db190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Expected results: It shouldn't crash.
Attached file test_open_xpi.js —
Group: firefox-core-security → core-security
Component: Untriaged → Networking: JAR
Product: Firefox → Core
Most serious exploit risk is via jar: URIs which are available to content without prompting.
Keywords: csectype-bounds, sec-high
(In reply to Benjamin Smedberg [:bsmedberg] from comment #2) > Most serious exploit risk is via jar: URIs which are available to content > without prompting. Interesting. I uploaded the POC to try here: jar:http://dcc.fceia.unr.edu.ar/~ggrieco/crash.jar!/Z%C2%A9
Group: core-security → network-core-security
Is this something you could look into, Aaron? Thanks.
Flags: needinfo?(aklotz)
sec-high, affects 41 and 44, likely affects the releases in between.
status-firefox41: --- → affected
status-firefox42: --- → affected
status-firefox43: --- → affected
status-firefox44: --- → affected
tracking-firefox42: --- → ?
tracking-firefox43: --- → +
tracking-firefox44: --- → +
Yeah, Taras would usually send me all the libjar bugs anyway.
Assignee: nobody → aklotz
Flags: needinfo?(aklotz)
I was wondering if is it really necessary to support jar: links nowadays?
Attached patch Patch (obsolete) — — Splinter Review
Attachment #8671481 - Flags: review?(mwu)
Comment on attachment 8671481 [details] [diff] [review] Patch Review of attachment 8671481 [details] [diff] [review]: ----------------------------------------------------------------- This looks right to me. I'm really surprised that nsJARInputStream::Read is using mOutSize to determine how much data we can copy. mZs.avail_in/nsZipItem::Size() is what bounds the data we can read from the buffer and the nsZipCursor code correctly uses that for STORED entries. If you can get a pointer from nsZipArchive::GetData, it guarantees that up to nsZipItem::Size() bytes can be read. Maybe we can make nsZipArchive::GetData do more sanity checking instead? This would also protect other users of nsZipArchive like nsZipCursor/nsZipItemPtr and make it slightly less obvious which code path is handling broken STORED entries wrong.
Attached patch Patch (r2) (obsolete) — — Splinter Review
This revision moves the check into nsZipArchive and also revises nsJARInputStream::Read to use the safer variable.
Attachment #8671481 - Attachment is obsolete: true
Attachment #8671481 - Flags: review?(mwu)
Attachment #8671527 - Flags: review?(mwu)
Comment on attachment 8671527 [details] [diff] [review] Patch (r2) Review of attachment 8671527 [details] [diff] [review]: ----------------------------------------------------------------- r=me without the changes in jsJARInputStream.cpp, which I think we can tackle separately. ::: modules/libjar/nsJARInputStream.cpp @@ +205,5 @@ > break; > > case MODE_COPY: > if (mFd) { > + uint32_t count = std::min(aCount, uint32_t(mZs.avail_in) - uint32_t(mZs.total_out)); I think this is a little weird - avail_in is suppose to be updated whenever we read data from the buffer, so this isn't quite right. I think it would be sufficient to stick with the fix in nsZipArchive.cpp and come back to this later if you want. ::: modules/libjar/nsZipArchive.cpp @@ +841,5 @@ > // -- check if there is enough source data in the file > if (!offset || > mFd->mLen < aItem->Size() || > + offset > mFd->mLen - aItem->Size() || > + aItem->Compression() == STORED && aItem->Size() != aItem->RealSize()) { Had to look up operator precedence to figure out if this was right. ::: modules/libjar/test/unit/test_corrupt_1211262.js @@ +1,5 @@ > +/* Any copyright is dedicated to the Public Domain. > + * http://creativecommons.org/publicdomain/zero/1.0/ > + */ > + > +// Regression test ensuring that that a STORED entry with differing comparessed s/comparessed/compressed/
Attachment #8671527 - Flags: review?(mwu) → review+
Attached patch Patch (r3) — — Splinter Review
Incorporated review feedback. Carrying forward r+.
Attachment #8671527 - Attachment is obsolete: true
Attachment #8671564 - Flags: review+
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Comment on attachment 8671564 [details] [diff] [review] Patch (r3) [Security approval request comment] How easily could an exploit be constructed based on the patch? Pretty easily; somebody would just need to generate a specially crafted ZIP that meets the condition in the patch. Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem? There is mentioning of ZIP corruption. Which older supported branches are affected by this flaw? All supported branches If not all supported branches, which bug introduced the flaw? N/A Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be? Should be a simple hg graft. No risk. How likely is this patch to cause regressions; how much testing does it need? Added a new xpcshell test for this condition. Other existing tests pass. Unlikely to cause regressions since our code doesn't support encrypted ZIPs (in that case the condition added by this patch would be incorrect).
Attachment #8671564 - Flags: sec-approval?
Sec-approval+ but the test needs to not land until after we ship a release with this fix so we don't 0 day ourselves by showing everyone how to easily trigger this. We'll want this on Aurora, Beta, and ESR38. Please nominate patches for these.
Attachment #8671564 - Flags: sec-approval? → sec-approval+
Attached patch Patch containing fix only (obsolete) — — Splinter Review
[Approval Request Comment] If this is not a sec:{high,crit} bug, please state case for ESR consideration: This is sec-high User impact if declined: A specially crafted ZIP file could be loaded (via jar:// url or other means) that causes Firefox to read invalid memory Fix Landed on Version: To be landed on 42, 43, 44 Risk to taking this patch (and alternatives if risky): Low, adds a simple sanity check String or UUID changes made by this patch: None See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info. Approval Request Comment [Feature/regressing bug #]: libjar [User impact if declined]: A specially crafted ZIP file could be loaded (via jar:// url or other means) that causes Firefox to read invalid memory [Describe test coverage new/current, TreeHerder]: Locally. Wrote regression test to be landed later once security fix is in release channel. [Risks and why]: Low, adds a simple sanity check [String/UUID change made/needed]: None
Attachment #8673241 - Flags: review+
Attachment #8673241 - Flags: approval-mozilla-esr38?
Attachment #8673241 - Flags: approval-mozilla-beta?
Attachment #8673241 - Flags: approval-mozilla-aurora?
Busted because MSVC doesn't give me those warnings. Fixed, carrying forward r+. See comment 15 for approval request info.
Attachment #8673241 - Attachment is obsolete: true
Attachment #8673241 - Flags: approval-mozilla-esr38?
Attachment #8673241 - Flags: approval-mozilla-beta?
Attachment #8673241 - Flags: approval-mozilla-aurora?
Flags: needinfo?(aklotz)
Attachment #8673327 - Flags: review+
Attachment #8673327 - Flags: approval-mozilla-esr38?
Attachment #8673327 - Flags: approval-mozilla-beta?
Attachment #8673327 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/673d9f45b802
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox44: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
Comment on attachment 8673327 [details] [diff] [review] Patch containing fix only (r2) OK to uplift to aurora and beta, looks ok on m-c.
Attachment #8673327 - Flags: approval-mozilla-beta?
Attachment #8673327 - Flags: approval-mozilla-beta+
Attachment #8673327 - Flags: approval-mozilla-aurora?
Attachment #8673327 - Flags: approval-mozilla-aurora+
ni? myself so that I remember to land the tests later.
Flags: needinfo?(aklotz)
Group: network-core-security → core-security-release
OK, here's the actual patch as landed on central. r2 *should* have been this one.
Flags: needinfo?(aklotz)
Attachment #8674353 - Flags: review+
Still need to ni? myself, oops.
Flags: needinfo?(aklotz)
Aaron, Tomcat: We will need this to patch to land on ESR branch too. Could you please uplift? Thanks!
Flags: needinfo?(cbook)
Comment on attachment 8673327 [details] [diff] [review] Patch containing fix only (r2) Taking this in esr38.4.0 as this is a sec-high which has also landed on Beta42 and Aurora43.
Attachment #8673327 - Flags: approval-mozilla-esr38? → approval-mozilla-esr38+
Flags: needinfo?(cbook)
Flags: sec-bounty?
Whiteboard: [adv-main42+][adv-esr38.4+]
While following STR provided in comment 0, indeed I cannot install the xpi file; and while using the testcase in Nightly debug from 2015-10-04, the build unexpectedly close under Ubuntu 12.04 64-bit. Is there any other xpi that I could test with? Or different STR? Aaron, what's your take on this? Gustavo, could you please check the latest builds to see if this is fixed for you? Thanks in advance!
Flags: needinfo?(gustavo.grieco)
Sure, i will test it later today. Indeed the xpi file cannot be installed but you can check this same bug using jar links (it is the same crasher, but accesing directly as zip). Just load this link into your firefox build: jar:http://dcc.fceia.unr.edu.ar/~ggrieco/crash.jar!/Z%C2%A9
Flags: needinfo?(gustavo.grieco)
(In reply to Gustavo Grieco from comment #32) > Sure, i will test it later today. Great! Thank you! > Indeed the xpi file cannot be installed but you can check this same bug using jar links (it is the same crasher, but > accesing directly as zip). Just load this link into your firefox build: > jar:http://dcc.fceia.unr.edu.ar/~ggrieco/crash.jar!/Z%C2%A9 Already tried it (via comment 3), but the file is no longer there: "The requested URL was not found on this server." is displayed.
It looks http://dcc.fceia.unr.edu.ar/~ggrieco/crash.jar is working correctly here. Have you copy and pasted the jar link directly into the browser address bar?
Alias: CVE-2015-7194
I can confirm: no crash in the last build from tinderbox (20151020150039). I tried the jar: link and the xpcshell test script. Great job guys! (btw, i'm running QuickFuzz again just in case)
(In reply to Gustavo Grieco from comment #35) > I can confirm: no crash in the last build from tinderbox (20151020150039). I > tried the jar: link and the xpcshell test script. Great job guys! > > (btw, i'm running QuickFuzz again just in case) Thanks, Gustavo! Marking accordingly based on your result.
Status: RESOLVED → VERIFIED
status-firefox44: fixed → verified
Flags: sec-bounty? → sec-bounty+
The unit test has landed.
Flags: needinfo?(aklotz)
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: