1759951 - (CVE-2022-36317) DOS - The long parameter makes the user have to delete the Firefox browser Android

Status: RESOLVED FIXED

(Fenix :: General, task, P2)

Description

[Irwan]

Attachment: open this to get the DoS link

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

2. 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:

• https://drive.google.com/file/d/1j3_IfXna1TgcHe8uZgnWVmLj10T4XFFv/view

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

Comment 1

[Irwan]

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

Comment 2

[Kevin Brosnan [Ex-Mozilla]]

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.

Comment 3

[Irwan]

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.

Comment 4

[Irwan]

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

Comment 5

[Irwan]

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.

Comment 6

[Irwan]

hi, can you guys produce this problem?

Comment 7

[Daniel Veditz [: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

Comment 8

[Irwan]

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?

Comment 9

[Irwan]

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

Comment 10

[Irwan]

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.

Comment 11

[Christian Sadilek [:csadilek]]

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.

Comment 12

[Irwan]

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

Best, Regards...

Comment 13

[Daniel Veditz [:dveditz]]

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

Comment 14

[Irwan]

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.

Comment 15

[Irwan]

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..

Comment 16

[Irwan]

Attachment: Screenshot_2022-03-24-19-55-45-18_0b2fce7a16bf2b728d6ffa28c8d60efb.jpg

?

Comment 17

[Daniel Veditz [:dveditz]]

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.

Comment 18

[Irwan]

HI any update?

Comment 19

[Daniel Veditz [:dveditz]]

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.

Comment 20

[Christian Sadilek [: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.

Comment 21

[Irwan]

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

Comment 22

[Irwan]

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,

Comment 23

[Irwan]

is there an update there?

Comment 24

[Christian Sadilek [:csadilek]]

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.

Comment 25

[Christian Sadilek [:csadilek]]

Attachment: profile.json.gz

Comment 26

[Irwan]

do you guys have any updates there?

Comment 27

[Amedyne Moya [:amoya]]

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

Comment 28

[Irwan]

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

Comment 29

[[:skhan]]

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

Comment 30

[[:skhan]]

Attachment: 0001-Improve-search-term-performance-on-the-toolbar.patch

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.

Comment 31

[Irwan]

Attachment: Oppo device.jpg

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

Comment 32

[Irwan]

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

Comment 33

[Chris Peterson [:cpeterson]]

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 34

[Tom Ritter [:tjr]]

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.

Comment 35

[[:skhan]]

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

Comment 36

[Irwan]

Any update?
I see Firefox has entered version 101?

Comment 37

[[:skhan]]

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

Comment 38

[Ryan VanderMeulen [:RyanVM]]

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

Comment 39

[Irwan]

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

Thnks...

Comment 40

[Kevin Brosnan [Ex-Mozilla]]

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.

Comment 41

[Chris Peterson [:cpeterson]]

(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?

Comment 42

[[:skhan]]

@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

Comment 43

[Daniel Veditz [:dveditz]]

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?

Comment 44

[Daniel Veditz [:dveditz]]

[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.

Comment 45

[Irwan]

Thank you Daniel for the reply and the reward.

Comment 46

[Frederik Braun [:freddy]]

Attachment: advisory.txt

Comment 47

[Irwan]

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

Comment 48

[Chris Peterson [: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.

Comment 49

[Irwan]

Thank you @criss
Have verified this issue..

Comment 50

[Christian Sadilek [:csadilek]]

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.

Comment 51

[Christian Sadilek [:csadilek]]

Attachment: profile-nightly-0914.json.gz

Comment 52

[Chris Peterson [:cpeterson]]

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.

Comment 53

[Chris Peterson [:cpeterson]]

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

Comment 54

[[:skhan]]

That's correct Chris!

Comment 55

[Chris Peterson [:cpeterson]]

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

Comment 56

[Irwan]

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

Comment 57

[Kevin Brosnan [Ex-Mozilla]]

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.

Comment 58

[Irwan]

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..

Comment 59

[Irwan]

(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

Comment 60

[Irwan]

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

Comment 61

[Chris Peterson [:cpeterson]]

Bug 1790913 has already been verified as fixed in 108.

Comment 62

[Irwan]

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

Comment 63

[Chris Peterson [:cpeterson]]

(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.)

Comment 64

[Irwan]

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

Comment 65

[Irwan]

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

Comment 66

[Irwan]

Any update team

Comment 67

[Irwan]

Any update?

Comment 68

[Irwan]

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

best regards

Comment 69

[Irwan]

hi can someone reply to my question?

I asked if the second problem from this ticket also got a bounty?

Comment 70

[Daniel Veditz [:dveditz]]

Bounty questions should be directed to [e-mail]. 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.

Comment 71

[Irwan]

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

Comment 72

[Irwan]

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

Comment 73

[Irwan]

Attachment: IMG_7561.jpeg