<a class="header-button" href="https://bugzilla.mozilla.org/home" title="Go to home page"> Bugzilla

Reporter

Comment 1

•

3 years ago

Attached file firefox.rar — Details

Reporter

Updated

•

3 years ago

Points: --- → 8

OS: Unspecified → Windows 10

Hardware: Unspecified → Desktop

Comment 2

•

3 years ago

(In reply to Sabuhi from comment #0)

Created attachment 9275136 [details]
payload.txt

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.127 Safari/537.36

Steps to reproduce:

Example in the video on any site (comptia site). Firefox DOS is affected when 1 and 0 are sent to the input on a large scale.

It's not clear from the video - are you pasting into the text field? What are you pasting? And just once or multiple times?

(In the window that opens, report to Firefox information is given).

Can you open about:crashes and provide links to the crashes that correspond to this?

Points: 8 → ---

Flags: needinfo?(iismayilovsabuhi)

Summary: DOS on browser → DOS on browser when user provides very large inputs

Comment 3

•

3 years ago

(I've tried pasting the payload in the text file in a simple input field in data:text/html,<input> and this does not crash for me on current nightly...)

Comment hidden (obsolete)

Comment hidden (duplicate)

Comment 7

•

3 years ago

(In reply to Sabuhi from comment #4)

Created attachment 9275223 [details]
firefox.PNG

Reply.2nd

These aren't submitted - can you submit them and then copy-paste the link as a comment here?

Flags: needinfo?(iismayilovsabuhi)

Reporter

Comment 8

•

3 years ago

Hello, thank you!
Thanks.
Now I made the same DOS to the browser input you sent.
So we got the same error in the input you sent, and I will add the ReportID and screen recording to the topic.
Please also check the ReportIDs. Here the Browser will crash again.

Flags: needinfo?(iismayilovsabuhi)

Reporter

Comment 9

•

3 years ago

Attached file video screen and payload.rar — Details

video screen and payload

Reporter

Comment 10

•

3 years ago

İ have been submitted crashes.

Comment 11

•

3 years ago

(In reply to Sabuhi from comment #10)

İ have been submitted crashes.

Please can you share the links? The about:crashes page has "view" links on the right end of the table, copy those links and paste them in a comment please - without them, most of us won't be able to correlate specific crashes with this bugreport.

Flags: needinfo?(iismayilovsabuhi)

https://crash-stats.mozilla.org/report/index/e073a00f-0103-47b0-b9e6-a4ed70220505

Reporter

Comment 12

•

3 years ago

https://crash-stats.mozilla.org/report/index/61efdd3e-5c4d-42ae-aec3-7673c0220505

Flags: needinfo?(iismayilovsabuhi)

Comment 13

•

3 years ago

Both of those crashes are content crashes (ie tab crashes) - but the screencast shows that the parent process also crashes, and the crashreporter comes up. Can you submit crash reports for those crashes, and share the links here?

At least these content process crashes are in the webrender code when finishing building display lists, attempting to alloc 200 or 400mb, so moving over there so graphics folks can chime in.

Group: firefox-core-security → gfx-core-security

Component: Untriaged → Graphics: WebRender

Flags: needinfo?(iismayilovsabuhi)

Product: Firefox → Core

Reporter

Comment 14

•

3 years ago

Hello , thank you for comment.
So, Now you can look at the ReportIDs I've added here. The 2 reportIDs I sent so far were only the data (input) you sent, I guess that's why you couldn't see the log.
Now if you check these ReportIDs you will see for sure. As you have highlighted, the Parent Process is being stopped. It is clear that it is clear that there is a DOS in the middle.

Flags: needinfo?(iismayilovsabuhi)

Andrew McCreight [:mccr8]

Comment 15

•

3 years ago

At least https://crash-stats.mozilla.org/report/index/0ba440b0-98dd-471e-99eb-ec72c0220506 is a parent process crash, though I don't understand from the crash info why we would be crashing - it's an 8MB alloc request but there's 7.5gb available physical memory. It's also nowhere near graphics code - though the other content crashes (and at least one gpu crash that I spotted) look graphics related.

Dan/Andrew, do you have ideas on how to move forward here?

Flags: needinfo?(dveditz)

Flags: needinfo?(continuation)

Comment hidden (duplicate)

Comment 17

•

3 years ago

(In reply to :Gijs (he/him) from comment #15)

At least https://crash-stats.mozilla.org/report/index/0ba440b0-98dd-471e-99eb-ec72c0220506 is a parent process crash, though I don't understand from the crash info why we would be crashing - it's an 8MB alloc request but there's 7.5gb available physical memory. It's also nowhere near graphics code - though the other content crashes (and at least one gpu crash that I spotted) look graphics related.

The page file is getting a bit low. It might be the case that the content process is swamping the system so much that the parent process ends up crashing sometimes. You might even get some weird issue where both processes OOM crash at the same time, and you get some kind of race condition where whatever memory scanning the crash reporter does (is it done live in the crash reporter?) ends up measuring the value after the other process is cleaned up by the OS.

This might just be showing up as a crash in graphics code because graphics does the most allocation, so if some other thing is allocating a lot it shows up there. I'm not really sure what the test case is doing, as I don't have the ability to look at RAR files. There are lots of ways to swamp the browser. I don't know if this particular one is important to fix or not.

Status: UNCONFIRMED → NEW

Ever confirmed: true

Flags: needinfo?(continuation)

Keywords: csectype-dos

Updated

•

3 years ago

Attachment #9275223 - Attachment is obsolete: true

Flags: needinfo?(dveditz)

Comment 18

•

3 years ago

bp-49b0e05e-73d3-41fa-a5c7-dd4300220506 is a parent crash requesting only 96 bytes, with System Memory Use Percentage at 76% -- why is such a small request failing with that much memory available?! The notes do say that a small request can trigger the allocation of a new page for the pool, and that's probably what happened. But we should still have plenty of memory for that. Supposedly there's almost 8G of memory available.

The my.comptia.org site keeps giving me a server error so there's no way to try to reproduce this currently.

Reporter

Comment 19

•

3 years ago

Hello. Thank you for carefully reviewing the report. I repeated the process several times. I sent 12 logs. As you mentioned in the logs, we see that the parent process has crashed. The videos I sent clearly reflect this process. I believe that you will evaluate the report fairly and critically. Thank you again.

bp-6fc70c77-5839-4894-a262-a4df40220510

Comment 20

•

3 years ago

It's not so simple. Clearly your own machine crashed, but maybe you were out of memory! If you drive your car until it runs out of gas it is going to stop -- that's just the laws of physics and not the car's fault. On the other hand, if the car ran out of gas because there's a hole in the gas tank then that is a "bug" in the car. In order to find that "hole" we need to be able to examine it, and just seeing a picture of the car zooming by doesn't let us watch under the hood when the problem happens.

Finally got access to the my.comptia.org site and tried the described steps. I did manage to get the content process to crash, but it was an IPC null deref and not an OOM. It was, however, a message being sent from WebRender so that sort of lines up with the reporter's crashes being graphics-related. I had to paste the larger of the two payload.txt files (8.9Mb) into 3 fields before it crashed. Available memory seemed fine.

Comment 21

•

3 years ago

It was fairly consistent in reproducing a crash on Mac: paste into 3 fields and bp-f82316b5-baab-4dc9-b0b1-e2d940220510

No parent crash, but it's suspiciously busy.

Reporter

Comment 22

•

3 years ago

Hello , have a good day. Thank you for interest and efforts dear team.!
Dear Daniel , So

"""""bp-49b0e05e-73d3-41fa-a5c7-dd4300220506 is a parent crash requesting only 96 bytes, with System Memory Use Percentage at 76% -- why is such a small request failing with that much memory available?! The notes do say that a small request can trigger the allocation of a new page for the pool, and that's probably what happened. But we should still have plenty of memory for that. Supposedly there's almost 8G of memory available.""""

I am quoting this text from your comment above. Please note this reportID- bp-49b0e05e-73d3-41fa-a5c7-dd4300220506
It is already obvious that there is an Out of Memory error. Confirmed above when there are no graphics errors.
But I don't understand in what sense it is not understood. There is a bug, it is true, we should work together to solve it and solve it. Please change the status of the report as acceptable, I think it would be the right decision.

Comment 23

•

3 years ago

I wasn't saying this bug can't cause the parent to crash, I was saying that in my testing I did not observe that to happen. Doesn't mean it can't happen, but if we can't observe it it will be harder to see where the problem is coming from and fix it.

Updated

•

3 years ago

Has STR: --- → yes

Keywords: crash, sec-low

Summary: DOS on browser when user provides very large inputs → Crash on browser when user provides very large inputs

Andrew McCreight [:mccr8]

Reporter

Comment 24

•

3 years ago

Hello Mr Daniel Veditz, have a good day. Thank you for update.
I see it has been updated to Low status in the report. Why is crashing the brauzer with large input marked as low level? The status of the report still remains as the approval process. Can you please update..

Comment hidden (duplicate)

Comment 27

•

3 years ago

Resource exhaustion crashes like this tend to not be a very high priority, unfortunately, so I'm not sure how long it will be until somebody has a chance to investigate this further.

BugBot [:suhaib / :marco/ :calixte]

Reporter

Comment 28

•

3 years ago

Hello first.
You're totally wrong, I'd like to let you know.
Out of Memory is a bug, I have implemented a DOS that also stops the parent process, and you are telling me that someone will review it when they have time.
If the action you should definitely do is,
By accepting the bug report, you pay the bounty amount. Then we can go into the fix process together.

Comment hidden (offtopic)

Comment hidden (duplicate)

Comment hidden (offtopic)

Comment 32

•

3 years ago

The severity field is not set for this bug.
:gw, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(gwatson)

Updated

•

3 years ago

Severity: -- → S2

Flags: needinfo?(gwatson)

Comment hidden (duplicate, offtopic)

Comment hidden (duplicate)

Comment 35

•

3 years ago

•

Edited

(In reply to Sabuhi from comment #31)

The same vulnerability I reported to Google Chrome was closed last month.

Can you link to the chromium ticket?

(Also, please stop commenting on this ticket every other day. It does not accomplish anything.)

Flags: needinfo?(iismayilovsabuhi)

Reporter

Comment 36

•

3 years ago

Hello ,
I will not comment. Agreed, but I request you to speed up the process a bit.
Now I made a bug report to Google - not from Chromium, but directly from Google (Bug White HAT).
And it is not public in any way.

Let's think of it this way. If you had told me not to make this report public, if Safari security team had told me tomorrow, how would it be correct for me to share this bug report?
I am an ethical hacker.
It wouldn't be right for me to do this. I hope you understand.

Flags: needinfo?(iismayilovsabuhi)

Comment 37

•

3 years ago

(In reply to Sabuhi from comment #36)

Hello ,
I will not comment. Agreed, but I request you to speed up the process a bit.
Now I made a bug report to Google - not from Chromium, but directly from Google (Bug White HAT).
And it is not public in any way.

Please provide the link. When different browser vendors fix security issues that affect multiple browsers, it's usually considered polite not to mark reports public until fixed everywhere, and for that to happen we need to be able to coordinate with the chromium team. We can't do that without the link (but the link alone doesn't give us any confidential information, it likely won't be publicly accessible anyway).

(In reply to Sabuhi from comment #36)

Let's think of it this way. If you had told me not to make this report public, if Safari security team had told me tomorrow, how would it be correct for me to share this bug report?

Well, presumably the reports contain pretty similar information? Anyway, as I said, I'm only asking for the link.

Flags: needinfo?(iismayilovsabuhi)

Reporter

Comment 38

•

3 years ago

(In reply to :Gijs (he/him) from comment #37)

(In reply to Sabuhi from comment #36)

Hello ,
I will not comment. Agreed, but I request you to speed up the process a bit.
Now I made a bug report to Google - not from Chromium, but directly from Google (Bug White HAT).
And it is not public in any way.

Please provide the link. When different browser vendors fix security issues that affect multiple browsers, it's usually considered polite not to mark reports public until fixed everywhere, and for that to happen we need to be able to coordinate with the chromium team. We can't do that without the link (but the link alone doesn't give us any confidential information, it likely won't be publicly accessible anyway).

(In reply to Sabuhi from comment #36)

Let's think of it this way. If you had told me not to make this report public, if Safari security team had told me tomorrow, how would it be correct for me to share this bug report?

Well, presumably the reports contain pretty similar information? Anyway, as I said, I'm only asking for the link.

Hello. I understand you. However, as I mentioned, I will not be able to share this information with you, even if it is a link. Because it's my teammate who reported the other vulnerability. We made this report as a team. And he absolutely refuses to share this information.
The vector was not the same when I said the same vulnerability. So the attack was applied in a different way. What I was trying to tell you was just that they rewarded the report in a short time.
Here to Fix -
There is definitely a problem with the 8GB filter you have applied. This written and verified Rule is not configured correctly. You can perform a check and rebuild on it. And if this is determined for all inputs and browser discovery, it is necessary to look at them.

Comment hidden (duplicate)

Reporter

Updated

•

3 years ago

Flags: needinfo?(gwatson)

Comment 40

•

3 years ago

I cannot reproduce this locally so far. Has anyone else been able to reproduce it locally?

Flags: needinfo?(gwatson)

Reporter

Comment 41

•

3 years ago

(In reply to Glenn Watson [:gw] from comment #40)

I cannot reproduce this locally so far. Has anyone else been able to reproduce it locally?

Hello. Bug fixed. When I try to repeat the problem, I get another mistake. The error I received when submitting the first report: https://crash-stats.mozilla.org/report/index/0ba440b0-98dd-471e-99eb-ec72c0220506

“Process Type parent
MOZ_CRASH Reason (Sanitized)
MOZ_CRASH (OOM) ”was this.

When I repeat the same process, I get another error: https://crash-stats.mozilla.org/report/index/366449bb-807c-44a8-a426-807190220609

Process Type parent
MOZ_CRASH Reason (Sanitized)
MOZ_CRASH (IPC message size is too large)

Flags: needinfo?(gwatson)

Comment 42

•

3 years ago

There is no need to continue adding needinfos, we're aware of this bug and on the CC list.

Flags: needinfo?(gwatson)

Comment hidden (duplicate)

Comment 46

•

3 years ago

(In reply to Sabuhi from comment #45)

Hello.
I'm sorry to bother you, but I was wondering if there were any updates since our last conversation.

I have already told you, please stop commenting just to ask for updates. Any updates will appear on the bug, there is no point in asking for them. We don't have a separate "hidden" bug tracker - any and all updates will appear on this bug, and you will get email for them. All you're doing by commenting all the time is annoying everyone copied in on this report.

This bug report is not closed, because you indicated in comment #41 that the parent process is still crashing.

As noted in various other comments, we can't reproduce that locally (instead, the child process crashes, cf. comment #21). As we also noted, in comment #27, resource exhaustion crashes aren't particularly high priority. In this case, it also requires a lot of user interaction (the user pasting really long strings multiple times), and the crashes are not exploitable (OOM or safe MOZ_CRASH crashes), further reducing priority.

(In reply to Sabuhi from comment #44)

When will the bounty be paid?

Normally bounties are not paid until bugs are closed and marked fixed, which per your own comments this bug is not.

However, Mozilla doesn't typically pay bounties unless bugs are rated sec-high or sec-critical, which is documented in our bounty policy. This bug is rated sec-low, so it is unlikely you will be paid a bounty even if/when the report is closed/fixed. Given your repeated insistence, I have nominated the bug for consideration by the bounty committee anyway, but that likely won't happen until/unless the report is closed. Please do not request updates on the bounty until that point.

Flags: sec-bounty?

Reporter

Comment 47

•

3 years ago

Attached file Screen 07-05-2022 10-23-39.rar — Details

Reporter

Comment 48

•

3 years ago

Attached file 010101.rar — Details

Reporter

Comment 49

•

3 years ago

Hello. For the sec-bounty tag, first of all I thank you.
Please review the status of the bug report (sec-low). Sec-low status is valid if the bug does not affect other users. In the video I sent you, you can see that other users are also affected. Please consider this point. Re-evaluate the priority and status of the report.

You ask me not to write a comment. But you don't give any deadline about when the report will be resolved. Please let me know about the deadline.

Note: I am reattaching the html file used in the video.

Comment hidden (duplicate)

Comment 51

•

3 years ago

(In reply to Sabuhi from comment #49)

Please review the status of the bug report (sec-low). Sec-low status is valid if the bug does not affect other users. In the video I sent you, you can see that other users are also affected.

The video shows someone downloading a 74mb .html file off gdocs, then opening the downloads folder using the downloads panel context menu, then right clicking the file and opening it with Firefox. That's a lot of steps that you would need to convince a user to take, and in the end the result is that their browser tab (but not the main process!) crashes with no other adverse effects. So it appears from the video that the resulting crash is NOT the same one you've reported here (where the parent process crashed), and the contents of the testcase file are unwieldy so it's difficult to see what it does (74mb of what appear to be just 0s and 1s?).

If you could convince the user to take these steps, it would be much simpler to convince the user to run an executable that properly pwned their machine instead.

(In reply to Sabuhi from comment #50)

Why is no one answering?

Well, I personally was out sick, but in general, I expect that people found your comments not very actionable - you gave no description of how you were making this affect third parties, instead attaching an archived video in an annoying format that required taking a bunch of extra steps to watch. In future, I would suggest attaching a webm video that just displays inline, or if it's too big for that, uploading to youtube or similar as a private upload and sharing a link and describing what is happening in the video in text form in the bug.

As I have already explained, this bug isn't high priority right now. The video hasn't changed that.

What is the maximum time for a bug to be fixed? What is the maximum time a report can stay in the new state? How long does it take to resolve a report?

There isn't a deadline. Like most open source projects, we get more bugreports than we can fix. Here are some bugs that have been in the "NEW" state for over 20 years.

In the video I shared recently, I showed you with an example that I can influence third parties.

As explained above, I am not convinced that this is the same issue, or that it's a reasonable to expect users to jump through all those hoops and that that changes the severity of the issue.

If just loading a remote webpage (not downloading it first and then jumping through hoops to load it off the disk) without further user interaction crashed the parent process (rather than the tab process) reliably, that might warrant increasing the security severity and the bug's priority, but that isn't what you're showing.

Comment hidden (admin-reviewed)

Comment hidden (offtopic)

Timothy Nikkel (:tnikkel)

Updated

•

3 years ago

Flags: needinfo?(gwatson)

Comment hidden (offtopic)

Comment hidden (duplicate, offtopic)

Comment hidden (duplicate)

Comment hidden (duplicate, offtopic)

Comment 60

•

3 years ago

Without debugging this particular case this sounds like the same basic crash reason as bug 1772994 (too large display list being sent over ipc).

Comment 61

•

3 years ago

and? What do you propose to do? The parent process has crashed. and this problem is not taken seriously. It is neither fixed nor given a status. what do you suggest What to do?

Timothy Nikkel (:tnikkel)

Comment 62

•

3 years ago

(In reply to Sabuhi from comment #61)

and? What do you propose to do? The parent process has crashed.

As Dan and I both said in comment #20 and comment 51, we can't reproduce the parent process crashing.

and this problem is not taken seriously.

An OOM crash isn't normally exploitable and so not super serious - it's basically a denial of service attack - and at this point it's not clear if/how you are crashing the parent process (ie we don't have clear/reproducible steps from you that actually crash the parent), so there's not much we can do to fix it, either.

Comment hidden (admin-reviewed)

Comment 64

•

2 years ago

I think bug 1817184 has now fixed all the crashes that have been presented here.

Depends on: 1817184

Comment hidden (duplicate)

Comment hidden (offtopic)

Comment hidden (advocacy, duplicate)

Comment hidden (offtopic)

Comment 70

•

2 years ago

(In reply to Sabuhi from comment #56)

Hello security team.

The "security team" should be addressed through the security mailing address found in our Bug Bounty Program. Once a bug has been handed over to the appropriate engineering team the security team generally has a higher-level coordination and management role and isn't directly involved and won't see your comments until much later.

Questions about the bounty, in particular, don't belong in the bug because it gets in the way of the engineers working here and they can't answer your questions anyway.

(In reply to Sabuhi from comment #63)

your inability to reproduce does not indicate the absence of a bug.

That's very true, but it does hinder our ability to understand and fix it

I have sent you a video and logs showing how I crash the parent process.

A small but crucial distinction: your video shows you crashing the process, but it does not show HOW.

A more skilled hacker can exploit a bug that you think doesn't deserve to be fixed.

That's true! Our bug bounty program is designed in part to reward those skilled hackers for showing us where we are wrong. In this case, however, all the evidence we have shows that this bug is a simple Denial of Service crash: Firefox has intentionally crashed itself to prevent the ability to abuse unexpected conditions, or been slapped down by the Operating System to preserve system stability.

(In reply to Sabuhi from comment #54)

Worst of all, we are not sure if the bounty will be paid out. And it's unclear when the bounty will be paid out. no deadline!

The bounty program (see link above) is actually very clear on that: "Denial of Service issues that merely crash the browser are not eligible for a bounty." You have claimed that this is more exploitable than that so we've being trying to get evidence, but it seems time to call it a DOS and move on. As a stability problem this rates low priority because the triggering conditions are extremely rare (essentially artificial). Crashes that happen to lots of people fairly often while browsing to normal websites are higher priority.

Group: gfx-core-security

Flags: sec-bounty?

Flags: sec-bounty-

Flags: needinfo?(tom)

Keywords: sec-low

Comment 71

•

2 years ago

(In reply to Sabuhi from comment #38)

The vector was not the same when I said the same vulnerability. So the attack was applied in a different way. What I was trying to tell you was just that they rewarded the report in a short time.

We, too, can fix and award a bug in a short time when the bug report is actionable. bug 1758062, for example, was reported March 3 last year, fixed on March 4, and awarded a bounty on March 8.

(In reply to myself from comment #70)

Crashes that happen to lots of people fairly often while browsing to normal websites are higher priority.

In the above I was talking about simple denial of service crashes with no evidence of other exploitability; their priority is determined on the bases of stability. Potentially exploitable crashes are separately prioritized based on security, not the frequency of crashes in the wild.

Comment 72

•

2 years ago

We think we've fixed bugs like what are described here, but we don't have enough information to know if we've actually fixed the full set. There are still OOM-related crashes in bug 1772994 that seem related.

Status: NEW → RESOLVED

Closed: 2 years ago

Resolution: --- → INCOMPLETE