1335684 - "Throw Exception" tab crash @ OOM | small

Status: RESOLVED WONTFIX

(Core :: Audio/Video: Playback, defect, P3)

Description

[Dhiraj Mishra]

Attachment: tab.html

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170125094131

Steps to reproduce:

Steps to Reproduce :

1. Open tab.html 
2. The Tab crashes 


I have tested multiple times and i have crash ID below.
Crash ID : 
https://crash-stats.mozilla.com/report/index/22743e4e-1022-4681-982f-2e6422170201
OR 
https://crash-stats.mozilla.com/report/index/16abd7fe-5279-4f0f-a8b7-dd9f72170201
OR 
https://crash-stats.mozilla.com/report/index/254a05f1-cc75-4481-b264-439302170201



Actual results:

Crash Reason : EXCEPTION_BREAKPOINT

Refresh twice if Crash doesn't happen. 
I am using :
Name 	Firefox
Version 	51.0.1
Build ID 	20170125094131
User Agent 	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
OS 	Windows_NT 6.1

Comment 1

[:Gijs (he/him)]

The nop_slep string you're throwing is doubled in length 64 times. So it starts at 1 character, and by the time the loop finishes it would be 18446744073709552000 characters long, which is several exabytes, and so of course we OOM (well before we reach that point, in fact). This isn't a security issue.

Comment 2

[ovidiu boca[:Ovidiu]]

I tested this issue on Windows 10 and with FF 51 release I can reproduce it but with FF Nighlty 54.0a1(2017-02-05) I can't reproduce the crash any more. Please note that on Mac this issue can't be reproduced with any version. 

Dhiraj can you please retest this with FF Nighlty? Please download the Firefox Nightly from here: https://nightly.mozilla.org/

Comment 3

[Dhiraj Mishra]

Yes ! I am not able to reproduce in FF Nighlty in Windows 7

Comment 4

[ovidiu boca[:Ovidiu]]

Thank you for your quick reply. I retest this with FF beta 52.0b3 (64-bit) and I can't reproduce it. Can you please confirm this by testing it? Here is the link from where you can download the latest beta: https://www.mozilla.org/en-US/firefox/channel/desktop/ 
If you can't reproduce it with this version I think the fix will land in the next FF release version around the date of 2017-03-07. Thanks for your time.

Comment 5

[Dhiraj Mishra]

I am able to reproduce it in FF Beta with a crash ID:
https://crash-stats.mozilla.com/report/index/c7b43101-ec8a-4012-90c0-cb3ec2170206

Comment 6

[ovidiu boca[:Ovidiu]]

In my case this issue doesn't reproduce on beta. I tested one more version where FF doesn't crash, developers edition. Do you think you can verify also this version? Here is the link to download and install it: https://www.mozilla.org/en-US/firefox/channel/desktop/

Comment 7

[Dhiraj Mishra]

It works for me in Developers Edition as well in Win 7 with the crash ID :
https://crash-stats.mozilla.com/report/index/b93484f4-1097-4f60-9df3-2152c2170206

Please refresh the tab in case it doesn't work.

Comment 8

[Loic]

On my machine with FF52, the testcase has launched an alert of Microsoft Security Essentials.

Comment 9

[ovidiu boca[:Ovidiu]]

Dhiraj do you have any add-ons on your profile? If yes please try in safe mode: 
Please test if the issue can be reproduced in the safe mode of Firefox: https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

Comment 10

[Dhiraj Mishra]

Hi I have no add-ons and in Extensions I have FoxyProxy (The proxy Switcher)
However i have started fox in safe mode by pressing shift, the only difference i see, Crash ID is not generated rest the browser gets freeze.

Comment 11

[ovidiu boca[:Ovidiu]]

You can use a program called mozregression, that can help you finding the fix that solved this problem on Nighlty. First you need to install mozregression, use this link: http://mozilla.github.io/mozregression/install.html   ,here you can found all the steps that are needed to install it. 

After you have mozregression on your machine, the next step would be to open a command window and start using mozregression by typing "mozregression --bad year-month-day --good year-month-day --find-fix". You need to be sure that bad build is older than good build, otherwise this won't work.Usually the good build would be the latest Nightly so use that date. You can use for "bad year-month-day" "bad 2016-08-01" and for good "good 2017-02-05". You will have to test builds that will download and mark them bad or good depends if you can reproduce this issue.

Comment 12

[Dhiraj Mishra]

Sure, so is this is just for me or this build will be publicly updated as well.

Comment 13

[ovidiu boca[:Ovidiu]]

Sorry but I don't understand what you mean, can you please be more clear. Thanks

Comment 14

[Dhiraj Mishra]

So the above message of urs for finding the bug by mozregression is just for me as an individual or after I get patch for the builds will it be publicly updated ?

Comment 15

[ovidiu boca[:Ovidiu]]

What mozregression does is to find the fix that is in Nightly, you will not have an update.

Comment 16

[ovidiu boca[:Ovidiu]]

Hi, 
Any updates about this issue?

Comment 17

[Dhiraj Mishra]

Hi, 
Sorry, didn't checked the fix with mozregression probally will do tonight.

Comment 18

[Dhiraj Mishra]

Attachment: POC

PFA and let me know did i found the patch ?

Comment 19

[ovidiu boca[:Ovidiu]]

In the bottom right side you have "~3 steps left", that meens that you need to do aprox. 3 more steps before you can find the regression window. But from what I see you are on the good track.

Comment 20

[Dhiraj Mishra]

Attachment: POC-Mozz.png

Attaching the final POC which mozregression gave.

Comment 21

[Dhiraj Mishra]

Accroding to that :
https://reviewboard.mozilla.org/r/108706/diff/1#index_header 

Refrence : https://bugzilla.mozilla.org/show_bug.cgi?id=1334445
This will be the Patch for the Issue.

Hi Boca would you please take a look !

Comment 22

[ovidiu boca[:Ovidiu]]

Thanks Dhiraj, from what I see bug 1334445 is the blame one.  Gerald can you please take a look at this bug? It seems that mozregression point out 1334445. Thanks.

Comment 23

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

First, I see in attachment 8841157 [details] "Looks like the following bug has the changes which introduced the fix", so bug 1334445 allegedly helped -- Good news, then? :-)


Anyway, this makes little sense to me!

Bug 1334445 should only affect parsing of a subset of video files, those that contain MP4 AnnexB data.
But this test does not seem to include anything media-related!

The first reports (comment 0, comment 5) happened *before* bug 1334445 landed (which makes sense if it fixed things), but they do not show any stack traces within AnnexB or ByteWriter code.

The only relationship I can see between these crashes and bug 1334445 is the OOM situation: Bug 1334445 changes the way OOMs are handled in AnnexB-parsing code; they used to just crash when we were trying to read too much data, after this bug we just give up and free resources, but in the worst case the OOM may still happen somewhere else while the AnnexB parser holds onto big buffers -- but once again, we shouldn't be in this code with this test!

I could not reproduce the crash locally, even when adding back a MOZ_CRASH on ByteWrite::Write() failures.


Dhiraj, are you able to build Firefox? If yes, could you please apply the following small change, and see if your test crashes again for you? In which case, please let me know if you see a line starting with "*** ByteWriter" at the end of the log. (You may need to disable e10s to see it.)
Thanks in advance.

----------------------------------
diff --git a/media/libstagefright/binding/include/mp4_demuxer/ByteWriter.h b/media/libstagefright/binding/include/mp4_demuxer/ByteWriter.h
--- a/media/libstagefright/binding/include/mp4_demuxer/ByteWriter.h
+++ b/media/libstagefright/binding/include/mp4_demuxer/ByteWriter.h
@@ -59,17 +59,23 @@ public:
   {
     uint8_t c[8];
     mozilla::BigEndian::writeInt64(&c[0], aLongLong);
     return Write(&c[0], 8);
   }
 
   MOZ_MUST_USE bool Write(const uint8_t* aSrc, size_t aCount)
   {
-    return mPtr.append(aSrc, aCount);
+    bool success = mPtr.append(aSrc, aCount);
+    printf("*** ByteWriter[%p, vector@%p]::Write(src=%p, size=%z) -> %d\n",
+           this, &mPtr, aSrc, aCount, int(success));
+    if (!success) {
+      MOZ_CRASH();
+    }
+    return success;
   }
 
 private:
   mozilla::Vector<uint8_t>& mPtr;
 };
 
 } // namespace mp4_demuxer
 
----------------------------------

Comment 24

[Dhiraj Mishra]

Hey Gerald, 

Works perfect by adding that above lines the browser doesn't crash.
In Linux FF Nightly. 

Attaching the Video POC for reference.

Comment 25

[Dhiraj Mishra]

Attachment: Mozilla-Rebuild.mkv

Adding the Lines :

----------------------------------
diff --git a/media/libstagefright/binding/include/mp4_demuxer/ByteWriter.h b/media/libstagefright/binding/include/mp4_demuxer/ByteWriter.h
--- a/media/libstagefright/binding/include/mp4_demuxer/ByteWriter.h
+++ b/media/libstagefright/binding/include/mp4_demuxer/ByteWriter.h
@@ -59,17 +59,23 @@ public:
   {
     uint8_t c[8];
     mozilla::BigEndian::writeInt64(&c[0], aLongLong);
     return Write(&c[0], 8);
   }
 
   MOZ_MUST_USE bool Write(const uint8_t* aSrc, size_t aCount)
   {
-    return mPtr.append(aSrc, aCount);
+    bool success = mPtr.append(aSrc, aCount);
+    printf("*** ByteWriter[%p, vector@%p]::Write(src=%p, size=%z) -> %d\n",
+           this, &mPtr, aSrc, aCount, int(success));
+    if (!success) {
+      MOZ_CRASH();
+    }
+    return success;
   }
 
 private:
   mozilla::Vector<uint8_t>& mPtr;
 };
 
 } // namespace mp4_demuxer
 
----------------------------------

It doesn't crashes please have a look.

Comment 26

[Al Billings [:abillings - ex-MoCo]]

You checked in an .mkv video file for a patch?

Sec-approval only applies to security bugs in any case. See https://wiki.mozilla.org/Security/Bug_Approval_Process

Comment 27

[Dhiraj Mishra]

Hey Andrew, sorry for raising sec-approval flag, I tested with the code mention above and rebuild the FF .mkv file has a video POC of what i did, for the reference.

Comment 28

[Wayne Mery (:wsmwk)]

Dhiraj, can you still reproduce?

Comment 29

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:jimm, since the bug has high severity and recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 30

[Dhiraj Mishra]

Hi, I am still able to reproduce this on 103.0.2 (64-bit) tested on macOS Monterey. Thanks!

Comment 31

[Jim Mathies [:jimm]]

Windows flagged this html file as a threat.

Comment 32

[Daniel Veditz [:dveditz]]

Comment 31 is a bit of a non sequitur: one specific anti-virus identifying a file as malicious has nothing to do with whether we fix a bug or not. For one thing, if this were to be used in the wild it would be loaded over the network and never seen by that scanner! For another, if scanners are identifying it then it's been seen in the wild and that's all the more reason to make sure Firefox users aren't going to be exploited. I suspect Windows Defender has identified the shellcode string used in the PoC (presumably copied from a known exploit), which is completely irrelevant to the Firefox crash we see here which is due to the exponentially doubling nop_sled.

This is WONTFIX because there's no good way to prevent all resource exhaustion attacks when you have an arbitrary scripting environment. Ideally it would be nice to throw exceptions at the scripts in the window (and we do in many cases), but in many cases of a page being unreasonable we're happy enough crashing the tab to put an end to the shenanigans. The page did it to itself.

Crashing the parent process and taking down the whole browser is much more annoying to users, so that kind of bug is higher priority.

The old crash report links have expired but I think the crash signature must have shifted. Now I see [@ OOM | large | NS_ABORT_OOM | xpc::ErrorReport::Init ]. It's crashing when trying to report an error (presumably a failure caused by OOM). The allocation size is 3,221,225,520 which is not surprising given the testcase, but I AM surprised the whole script is apparently being passed to the error function. And that it's consistently crashing there, and not sometimes (for example) at the point the PoC created the JS string that big.
bp-65667020-149a-4650-891b-81bb00220909

The top of the crashing thread for posterity (line numbers are from Fx 104.0.1)

0 	NS_ABORT_OOM(unsigned long) 	xpcom/base/nsDebugImpl.cpp:674
1 	xpc::ErrorReport::Init(JSErrorReport*, char const*, bool, unsigned long long) 	js/xpconnect/src/nsXPConnect.cpp:210
2 	mozilla::dom::AutoEntryScript::~AutoEntryScript() 	dom/script/AutoEntryScript.cpp:96
3 	mozilla::dom::ScriptLoader::ProcessRequest(JS::loader::ScriptLoadRequest*) 	dom/script/ScriptLoader.cpp:1859
4 	mozilla::dom::ScriptElement::MaybeProcessScript() 	dom/script/ScriptElement.cpp:118
5 	nsHtml5TreeOpExecutor::RunScript(nsIContent*) 	parser/html/nsHtml5TreeOpExecutor.cpp:942
6 	nsHtml5TreeOpExecutor::FlushDocumentWrite() 	parser/html/nsHtml5TreeOpExecutor.cpp:838
7 	nsHtml5Parser::Parse(nsTSubstring<char16_t> const&, void*, bool) 	parser/html/nsHtml5Parser.cpp:339
8 	mozilla::dom::Document::WriteCommon(nsTSubstring<char16_t> const&, bool, mozilla::ErrorResult&) 	dom/base/Document.cpp:9993