1684667 - Firefox stop responding after pasting payload in search/address bar.

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect, P2)

Description

[[e-mail]]

Attachment: check.html

Summary:
I found strange behavior when I paste long crafted url in search/address bar. I should mention that I use default settings in all browsers, so my address and search bars are not separated.
Steps to reproduce:

1. Visit attached html page and click "Click here!" button. I viewed it locally, but you can put in anywhere, it doesn't matter. You can also manually generate payload and copy it in your clipboard.
2. Paste your clipboard contents in search/address bar. It's not required to press enter, and anyway, browser will freeze before you can press any button.
3. Browser will stop responding (cpu consumption will be too high)
   Payload:
   Can be crafted with python, or any program language
   Consists of two parts - 'https://google.com/?id=2' + '<div="" class="">a</div></div></div><!---></div>' * 10000
   You can use any domain in first part, and different multipliers in second part. Multiplier affects cpu consumption, higher multiplier -> higher consumption. I suppose 10000 will be enough to freeze Firefox on almost all processors.
   Tested on Windows 10 Pro and Kali Linux:
   Firefox Browser latest (84.0.1)
   Firefox ESR latest (78.6.0esr)
   Attack scenario:
   Victim copy/click anything on attacker website, and than try to search it via bar. Firefox will freeze, victim will force quit, all work in other tabs will be lost.
   Despite the fact that impact is relatively low, it can be an indicator of more serious bug. It also affects different browser editions and platforms, so I think it worth to report.

Comment 1

[[e-mail]]

Attachment: Generated payload

Comment 2

[[e-mail]]

I also experienced crashes on Firefox for IOS latest (30.0, IPhone 6) in almost the same situation.
Should I fill separate report?
Payload is more simple, but scarier (such things often indicates overflow issues)
Payload: "https://google.com/" + "A" * 1000000
This doesn't work on Desktop Firefox, but work in IOS edition.
Immediate crash:

1. When you manually paste this payload in address bar. (like in original report)
2. When you click on this long link in address bar history.

Delayed crash:
When you enabled "Offer to open copied links" and follow copied link. Browser will freeze, and if you will tap on address bar to "unfreeze" it, it will crash. Note, that this link is shortened on UI and can look like normal link. I should mention that shortened link will be stored in history, and user can tap on it accidentally lately, that will produce immediate crash from first paragraph.

Impact is the same as I mentioned earlier. It also can be an indicator of more serious bug, it's hard to know for sure now, due to complex IOS debugging, but I will investigate further.

Comment 3

[:Gijs (he/him)]

(In reply to [e-mail] from comment #2)

I also experienced crashes on Firefox for IOS latest (30.0, IPhone 6) in almost the same situation.
Should I fill separate report?

Yes, please file a separate additional report in bugzilla, in the Firefox for iOS product.

Comment 4

[Daniel Veditz [:dveditz]]

Can confirm. The reporter filed the iOS variant as bug 1684754 so I'll be hiding the comments related to that.

Comment 5

[[e-mail]]

I suppose, that bug 1684754 has different root case, affecting another component (not address bar), so I originally reported it separately. I've filled 1685067 to cover scenarios which was mentioned in comments here.
(In reply to Daniel Veditz [:dveditz] from comment #4)

Can confirm. The reporter filed the iOS variant as bug 1684754 so I'll be hiding the comments related to that.

Comment 6

[Marco Bonardo [:mak]]

Bug 1589602 is still open for long strings being slow, even if we catched most common cases already. But it's likely this is about recognizing the kind of string, for which we fixed a similar bug a few versions ago.
I'll profile it and see.

Comment 7

[Marco Bonardo [:mak]]

I suspect bug 1682434 reduced a lot the problem here, from the profile I see us spending time in the same area.
Could you please test with Firefox 85+?

The only other thing we could do here, that I plan doing actually, is to avoid highlighting fallback url heuristic results, they are the full url anyway, making it full bold doesn't bring any benefit and rather makes them less readable. It is an expensive highlight that has no real purpose.

Comment 8

[Marco Bonardo [:mak]]

I filed Bug 1687767 about another couple things where we can save some time to improve perf. Along with bug 1682434 it should pretty much affect the code path this bug is about.

Comment 9

[[e-mail]]

(In reply to Marco Bonardo [:mak] from comment #7)

I suspect bug 1682434 reduced a lot the problem here, from the profile I see us spending time in the same area.
Could you please test with Firefox 85+?

The only other thing we could do here, that I plan doing actually, is to avoid highlighting fallback url heuristic results, they are the full url anyway, making it full bold doesn't bring any benefit and rather makes them less readable. It is an expensive highlight that has no real purpose.

Can confirm, couldn't reproduce bug on Firefox Browser 85.0, Windows 10.

Comment 10

[Marco Bonardo [:mak]]

Thanks, it sounds like we're done here, the bug was fixed by bug 1682434, and performance was further improved with Bug 1687767.

I'm not setting any dependencies to avoid disclosing connections between this bug and the other public ones.

I don't think the cost of uplift is worth for ESR78 considered this is an uncommon DOS in the Address Bar and a sec-low. Feel free to chime in if you think differently.

Comment 11

[[e-mail]]

(In reply to Marco Bonardo [:mak] from comment #10)

Thanks, it sounds like we're done here, the bug was fixed by bug 1682434, and performance was further improved with Bug 1687767.

I'm not setting any dependencies to avoid disclosing connections between this bug and the other public ones.

I don't think the cost of uplift is worth for ESR78 considered this is an uncommon DOS in the Address Bar and a sec-low. Feel free to chime in if you think differently.

Absolutely agreed. Is it worth to request a CVE for that?

Comment 12

[Marco Bonardo [:mak]]

That's a question for the security team.

Comment 13

[Daniel Veditz [:dveditz]]

(In reply to Marco Bonardo [:mak] from comment #10)

I'm not setting any dependencies to avoid disclosing connections between this bug and the other public ones.

A year or so ago Bugzilla was fixed so that dependencies aren't shown if you can't see the hidden bug: it's OK to add these now. NOTE: "See Also" items are still 100% visible. So far only depends on/blocks/regressed by/regressions were fixed.

(In reply to Marco Bonardo [:mak] from comment #12)

[worth requesting a CVE?] That's a question for the security team.

You can ask (send mail to [e-mail]), but I don't know if we'd issue a CVE for a DOS like this.