Closed Bug 1759951 (CVE-2022-36317) Opened 2 years ago Closed 1 year ago

DOS - The long parameter makes the user have to delete the Firefox browser Android

Categories

(Fenix :: General, task, P2)

All
Android

Tracking

(firefox101 wontfix, firefox102 wontfix, firefox103 fixed, firefox104 fixed, firefox105 fixed, firefox106 fixed, firefox108 fixed)

RESOLVED FIXED
108 Branch
Tracking Status
firefox101 --- wontfix
firefox102 --- wontfix
firefox103 --- fixed
firefox104 --- fixed
firefox105 --- fixed
firefox106 --- fixed
firefox108 --- fixed

People

(Reporter: hackerone3117, Assigned: skhan)

References

()

Details

(Keywords: csectype-dos, dataloss, sec-moderate, Whiteboard: [reporter-external] [web-bounty-form][post-critsmash-triage][adv-main103+])

Attachments

(8 files)

Hi all,
I just tested DOS on several android browsers, I saw that your android version of Firefox is vulnerable to DOS, the impact is quite severe the user has to delete your Firefox browser so that Back to normal.

Production steps:

  1. Send this payload DOS via email (victim)
  • open the link in the attachment below.txt
  1. When the victim creates the payload link above, the Firefox browser will be exposed to DOS, which requires the victim to reinstall Firefox.

PoC videos:

Impact :
DOS This causes important data to be lost in the victim's browser because they have to delete the browser to return to normal, even users can switch to other browsers

Flags: sec-bounty?

addition: I just tested in all Firefox browsers, Firefox Beta & Firefox nightly. this DOS vulnerable. thank you ..
Regards,

Group: websites-security → mobile-core-security
Component: Other → Security: Android
Product: Websites → Fenix

I am able to interact with Firefox Nightly v100.0a1 on a Galaxy note 9. It is quite sluggish and on lower spec devices it might be a persistent DoS. We have some open issues on address bar perf.

I use Oppo A92 with 8 GB Ram, Firefox stops forever, because the DOS link doesn't close immediately, so the DOS link loads continuously. maybe you can take an example on chrome and edge, even if the service stops, the link is quickly issued and when opening the browser again the DOS link doesn't reload.

And also it works on all Firefox browsers not only at nightly but all Firefox android versions. Thank you greetings...

hi addition, I don't think this is a problem with the HP specs, but Firefox doesn't issue a DOS link after crashing, Firefox keeps reloading the link until it finally has to be uninstalled, chrome & edge also crashes when the DOS link is opened, but they immediately issue the link so that when opening a new tab it becomes normal.

hi, can you guys produce this problem?

Flags: needinfo?(kbrosnan)
Flags: needinfo?(dveditz)

I don't see what your movie shows. The app.leedfeeder.com page opens with a red background showing a screenful of "a/a/a/a/a/a", and then it redirects to the site's login page. No DOS

Flags: needinfo?(dveditz)

hi when the link is loaded, it will get an error 409, but when we will open another site then DOS will run. can you see the POC Drive above?

Like your team, @kevin Brosnan, managed to produce that problem?

Hi Daniel, this only works on the Android version of the Firefox browser not the desktop, maybe that's the error, to open the link above please send it via email.

Flags: needinfo?(kbrosnan)

Tested on a Pixel 3a. This does make the app slow, but it's still usable for me.

I think this is essentially https://github.com/mozilla-mobile/android-components/pull/7031 which addressed these cases and truncated URLs to 25K characters (based on Fennec) to prevent the UI from hanging. We could make this more conservative though.

Hi @christian thanks for producing this problem,
I just tripled the payload on a/a/a/a/... it crashes more.

Best, Regards...

Of course I tested on Android. I pasted into the address bar though. I didn't try to open it from a different app.

thanks Daniel, for your reply,
I'm sure the Cellphone equivalent to my cellphone will crash. Firefox can't be used, especially if I add a longer DOS payload.

Regards.

Hi all, I hope we are doing well behind the scenes for a security. when will a fix be applied for this bug, so that I can retest this issue.
Thnks..

Kevin: on desktop Firefox will eventually stop trying to restore sessions if it fails to start multiple times (3? 2?). Does Fenix do anything like that? If so we don't really have a problem here.

Flags: needinfo?(kbrosnan)

HI any update?

Redirecting comment 17 to Christian (and 18, too, while you're at it)

Irwan: none of us can really reproduce this as more than a minor temporary condition.

Flags: needinfo?(csadilek)

Session restoration work fines in this case i.e., it completes successfully without delays. The problem is the UI locking up (after) due to the big URL in Android's TextView, and potentially our URL detection.

Kevin and I will discuss again in the triage meeting.

Flags: needinfo?(csadilek)

thanks for your reply,
I think so too, this problem only happens fatally on medium standard android specs, I know you guys can't produce this because your android specs are above average.

best regards

As for the session problem, in the handpond specification below, the DoS runs fatally, the user must delete the browser data, so there are no session problems on low-spec mobile phones,

Status: UNCONFIRMED → NEW
Ever confirmed: true

is there an update there?

Created a profile and confirmed the slow down is caused by android.graphics.text.LineBreaker.nComputeLineBreaks. This is the same problem as originally reported in https://github.com/mozilla-mobile/android-components/issues/5249.

I should add that on the device I tested this on (Pixel 3a) it is eventually possible to navigate back or close the tab, but tapping the toolbar does cause a very significant delay, as seen in the profile above.

We will look into this again.

do you guys have any updates there?

Sarah, can you provide an update on where you are on the investigation for this? Thanks!

Flags: needinfo?(skhan)

I don't understand this valid issue took months, without the slightest update.

The issue is fixed and is in testing stages for several devices.

Flags: needinfo?(skhan)

Hi, I am attaching a patch for review. Below are some interesting findings:

  • That issue was only happening on some specific devices, on a Moto G5 with Android 7, we were not able to reproduce.
  • We believe it could be linked to the Android EditText implementation OS 10 and higher as the issue is not reproducible on versions below android 10.
  • Only the url and not the Search Terms had the shrinking applied to it and this is what the patch is doing.

[Security approval request comment]
How easily could an exploit be constructed based on the patch?
Not that easy because not that a common use case and we found out it was only happening on android versions 10 and above.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
Not really because it is more of a performance improvement as it's not a critical use case.

Which older supported branches are affected by this flaw?
All versions except devices that have android versions below 10.

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?
We don't need to backport it as it is just a performance improvement and not a critical use case but it could be easily backported.

How likely is this patch to cause regressions; how much testing does it need?
Pretty low risk. Performed manual test on different devices and did unit test.

Assignee: nobody → skhan
Attachment #9278013 - Flags: sec-approval?
Attachment #9278013 - Flags: review?(jonalmeida942)
Attachment #9278013 - Flags: review?(amejiamarmol)
Attachment #9278013 - Flags: review?(amejiamarmol) → review+
Attachment #9278013 - Flags: review?(jonalmeida942) → review+
Attached image Oppo device.jpg

Hi I have a device with the above specs it's still vulnerable to this DOS.

hi all, do i ping every day to see this ticket?

Sarah has a bug fix, but she's waiting for security review before committing the change to Firefox Nightly.

Will we want to uplift the fix to Beta 102 or a dot release for 101?

Comment on attachment 9278013 [details] [diff] [review]
0001-Improve-search-term-performance-on-the-toolbar.patch

sec-approval is not needed for severities less than high.

Attachment #9278013 - Flags: sec-approval?

Landed a fix in Android components and it will be available in nightly in the next update

Any update?
I see Firefox has entered version 101?

Flags: needinfo?(skhan)

Bug is fixed and verified and should be available in nightly version 103

Flags: needinfo?(skhan)
Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(kbrosnan)
Resolution: --- → FIXED

Can you please provide a link to the upstream AC commit for this fix?

Group: mobile-core-security → core-security-release
Flags: needinfo?(skhan)

hi, status has been fixed,
Does this bug deserve a reward?

Thnks...

The security team meets on a regular basis to determine that. This bug is on the list as noted by Bug Flags: hackerone3117 sec-bounty ? in the details section of this bug. It may be a few weeks to a month before they get to evaluate this bug.

(In reply to Sarah from comment #37)

Bug is fixed and verified and should be available in nightly version 103

Do we want to uplift this fix to Beta 102? Or can the fix ride the trains with 103?

@Ryan, Here's the link to the commit : https://github.com/mozilla-mobile/android-components/pull/12265/commits/506947ad2f2e2511fb07bc4643b079c71fe6772b

@Chris, it's just a performance improvement, not so critical, so we can just ride it with 103. No uplift required

Flags: needinfo?(skhan)
Whiteboard: [reporter-external] [web-bounty-form] [verif?] → [reporter-external] [web-bounty-form] [verif?][post-critsmash-triage]

it's just a performance improvement, not so critical,

A performance improvement that, for people with older/slower phones, might keep people from uninstalling/reinstalling Firefox thinking it's completely broken? What are our metrics for phone capabilities, and how many Fenix/Focus users have phones that would be that badly impacted?

[Bounty comment] This could be viewed as essentially a duplicate of earlier AC and Fenix reports (added to see-also), but we didn't fully fix the problem then and resolved those issues so we're going to count this as a separate bug. Normally DOS bugs aren't eligible for the bounty, but for some {unknown} percentage of users this could lead them into full profile loss if they uninstall.

Flags: sec-bounty? → sec-bounty+

Thank you Daniel for the reply and the reward.

Summary: DDOS - The long parameter makes the user have to delete the Firefox browser Android → DOS - The long parameter makes the user have to delete the Firefox browser Android
Flags: needinfo?(skhan)
Whiteboard: [reporter-external] [web-bounty-form] [verif?][post-critsmash-triage] → [reporter-external] [web-bounty-form][post-critsmash-triage][adv-main103+]
Attached file advisory.txt
Alias: CVE-2022-36317
Status: RESOLVED → VERIFIED

hi everyone,
I saw that this bug was fixed in version 103, but the latest version is now 104 DOS it still works.
Can you guys review this problem, I don't think it's fully fixed yet.

Thnks

Flags: needinfo?(cpeterson)

(In reply to Irwan from comment #47)

I saw that this bug was fixed in version 103, but the latest version is now 104 DOS it still works.
Can you guys review this problem, I don't think it's fully fixed yet.

Sarah, I'm reopening this bug because I can still reproduce this hang.

I just tested Firefox 104 and Nightly 106 on a Samsung Galaxy A32 (a mid-range device) running Android 12.

  1. Open this bug in Firefox.
  2. Click the link this bug's URL field.
  3. Firefox loads the "494 ERROR" page in a new tab without freezing. 🙂
  4. Close the "494 ERROR" tab and return the Bugzilla tab.
  5. Close the Bugzilla tab, returning to Firefox's home page.
  6. Then Firefox hangs. 🥶
  7. Force quit Firefox and launch it again.
  8. Firefox hangs again on the home page. 🥶

To recover, I have to clear Firefox's app storage data in Android's Settings.

Severity: -- → S2
Status: VERIFIED → REOPENED
Flags: needinfo?(cpeterson) → needinfo?(skhan)
Priority: -- → P2
Resolution: FIXED → ---

Thank you @criss
Have verified this issue..

The original patch here fixed the problem occurring in the toolbar, but I created a new profile based on Chris's STR, and it shows the same problem now being hit on the home fragment. We're hitting Android's android.graphics.text.LineBreaker.nComputeLineBreaks again which blocks for an extended period of time.

Let's truncate long URLs on all home screen sections, and also write an extension function so we don't keep running into this with new functionality.

Flags: needinfo?(skhan)
See Also: → 1790913

Since this toolbar hang with the original STR was fixed, I'll close this bug again and we can fix the homepage hang STR in bug 1790913.

OS: All → Android
Component: Security: Android → General

Sarah, did your fix for bug 1790913 in 108 also fix this bug in 108?

Flags: needinfo?(skhan)

That's correct Chris!

Flags: needinfo?(skhan)

Thanks. In that case, I'll resolve this bug as fixed in 108.

Status: REOPENED → RESOLVED
Closed: 2 years ago1 year ago
Depends on: 1790913
Resolution: --- → FIXED
See Also: 1790913

hi everyone,
I can't comment on ticket #1790913,
is this a separate bug? and do i also get separate bounties for these 2 issues?
I see the status has been fixed at 108

Best regards

If I remember we fixed the address bar DOS in this bug. When the reporter said that it was still happening we reinvestigated. We found that the some of the Jump Back in data that was added in between 103 and 106 had a similar flaw as the address bar. That was the bug Chris filed.

Hi @kevin,
as stated by your team @criss, this is DoS that multiplies in different STR, so he separated this issue to speed up the fix in ticket #1790913

As Irwan reported in bug #1759951 comment 47, this bug still reproduces with a different STR. Since the toolbar hangs with the original STR was fixed, I'm opening this new homepage bug for the new STR.

Best regards..

Flags: needinfo?(cpeterson)

(In reply to Christian Sadilek [:csadilek] from comment #50)

The original patch here fixed the problem occurring in the toolbar, but I created a new profile based on Chris's STR, and it shows the same problem now being hit on the home fragment. We're hitting Android's android.graphics.text.LineBreaker.nComputeLineBreaks again which blocks for an extended period of time.

Let's truncate long URLs on all home screen sections, and also write an extension function so we don't keep running into this with new functionality.

See Aslo

and can you add me to ticket #1790913, so I can comment there,

yesterday I experienced a problem with my account, making me removed from accessing the comments there

Bug 1790913 has already been verified as fixed in 108.

Flags: needinfo?(cpeterson)

hi @criss the problem has been fixed.
do I get re-rewarded for both different issues?

(In reply to Irwan from comment #62)

hi @criss the problem has been fixed.
do I get re-rewarded for both different issues?

I don't know how the bounties work, so I'll redirect your question to Daniel Veditz. (He's out on holiday until January 9.)

Flags: needinfo?(dveditz)

thanks @criss for following up on this issue,
have a nice holiday!

hi @criss can you please add me to the ticket #1802355, so this issue is separate so there is no confusion.

Flags: needinfo?(cpeterson)
Group: core-security-release

hi @daniel
does my second report also get the same reward,
because it has a different root cause?

best regards

Bounty questions should be directed to security@mozilla.org. Especially in resolved bugs comments tend to go unseen because people filter them out to deal with the deluge of mail about not-resolved bugs.

I've added a bounty flag to the other bug and it should get looked at next week.

Flags: needinfo?(dveditz)

thanks daniel for the confirmation
I think I've been kicked out of ticket #1790913 because my account was in trouble at the time, can I be invited again to access the report

hi @daniel

I see you give bounty+,
but i don't see it because i have exited the ticket, can you add me again there?

regards

Flags: needinfo?(dveditz)
Attached image IMG_7561.jpeg
Flags: needinfo?(dveditz)
You need to log in before you can comment on or make changes to this bug.