1827442 - Browser hangs when pasting very large string into URL bar

Status: NEW

(Core :: Layout: Text and Fonts, defect)

Description

[Gemilang]

Attachment: **summary** Hi team, I found that the Mozilla browser website is vulnerable to dos attacks, when users enter random numbers strings that have no restrictions.

steps to reproduce

1. open browser mozilla
2. go to https://www.browserling.com/tools/random-string
3. set numbers strings with length 128000000
4. paste in browser mozilla search

Comment 1

[Daniel Veditz [:dveditz]]

The attached picture shows the dialog from our crash reporter. Did you submit the crash? If so please enter "about:crashes" in the address bar, follow the relevant link to our website (to make sure it's submitted) and then paste that URL here. It should be on the domain https://crash-stats.mozilla.org/

Comment 2

[Andrew McCreight [:mccr8]]

I tried this myself on MacOS, and ran the profiler from Activity Monitor.

It looked like most of the time is being spent in text layout:
nsTextFrame::EnsureTextRun
BuildTextRunsScanner::FlushFrames
gfxFontGroup::InitTextRun

There's also a bit of a hang when you just try to copy that giant string into the clipboard, FWIW.

Comment 3

[Andrew McCreight [:mccr8]]

Attachment: MacOS hang sample

Comment 4

[Jonathan Kew [:jfkthame]]

This is neither new nor surprising; see e.g. bug 1800596.

Comment 5

[Jonathan Kew [:jfkthame]]

We could maybe mitigate this a bit, at the cost of potentially-incorrect display, by truncating what the URL bar displays (it's hard to imagine a case where displaying a multi-thousand-character URL or search string in its entirety would actually be useful). But it's basically just an example of generating ridiculously large content, and then complaining that it brings the browser to its knees.

(FWIW, neither Safari nor Chrome seems able to even construct such a giant string in the first place, let alone try and paste it into the url bar....)

Comment 6

[Gemilang]

(FWIW, neither Safari nor Chrome seems able to even construct such a giant string in the first place, let alone try and paste it into the url bar....)

yes, that's why i'm reporting to firefox team. because this bug doesn't work in chrome and safari. i tested it first in chrome, before finally reporting to you. try to input random numbers with the payloads i provided (if u want i can give u my payloads to confirm this). and paste it into your browser url, it will cause crashing and as you can see in the image i provided.
"why don't we make it a 413 response, like chrome does"

Comment 7

[Gemilang]

(In reply to Gemilang from comment #6)

(FWIW, neither Safari nor Chrome seems able to even construct such a giant string in the first place, let alone try and paste it into the url bar....)

yes, that's why i'm reporting to firefox team. because this bug doesn't work in chrome and safari. i tested it first in chrome, before finally reporting to you. try to input random numbers with the payloads i provided (if u want i can give u my payloads to confirm this). and paste it into your browser url, it will cause crashing and as you can see in the image i provided.
"why don't we make it a 413 response, like chrome does"

Comment 8

[Daniel Veditz [:dveditz]]

"why don't we make it a 413 response, like chrome does"

Chrome does no such thing. Chrome truncates the string so that it "works" (after pasting it was only 512000 characters long). Then that shorter string is submitted to Google search and the Google server returns the 413 error. With a shorter string (1000000 worked for me), or maybe more memory in your Firefox, Firefox will also submit the pasted text to Google search and get a 413 error.

Comment 9

[Daniel Veditz [:dveditz]]

ALthough the slowdown is in layout/text because of the ridiculous string length, a "fix" might be in the addressbar (to truncate like Chrome appears to). Might also be good to put limits on our URL handlers so we don't navigate to such a link from code and then try to display that long URL in the UI.

Now that blob; urls exist we don't need to support arbitrarily long data: urls just in case someone invents some clever idea.

Comment 10

[Daniel Veditz [:dveditz]]

Unfortunately Denial of Service bugs are excluded from our bug bounty program.

Comment 11

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Per comment 9, change the component to "Firefox: Address Bar" for more input.

Comment 12

[Chris Bellini (:cbellini)]

Would this be an editor bug as well, given that this behavior would happen in text fields in addition to the address bar? Perhaps we could split this bug out into two; one for input fields and a separate address bar bug to truncate the display of large input strings?

Comment 13

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

I was just trying to get this bug moving during triage.

cc Masayuki to see if this is something we can improve in editor (see comment 12).

Comment 14

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sickish, maybe slower respose)]

Well, too big string value is not expected from TextEditor. TextEditor just creates one Text node into the anonymous <div>. So, it requires too long consecutive memory space to store the text, and that's copied a lot in stack when using nsAutoString. So, <input> and <textarea> should have limit in the standards to fix it simply (even though the paste event handler needs to have the long string). IIRC, the boundary code of the layout and DOM does not work correctly with too long string because of int32_t (layout) vs. uint32_t (DOM). So, I don't think the editor module should do something ASAP...

Comment 15

[Mark Banner (:standard8)]

We are happy to add a workaround on the front-end side, however as this probably will affect more text boxes than just the address bar, we think it should be addressed on the layout side.

Comment 17

[Gemilang]

hai all, may i ask, is my report eligible to enter into the microsoft hall of fame program?

Regards,
Gemilang.

Comment 18

[:Gijs (he/him)]

(In reply to Gemilang from comment #17)

hai all, may i ask, is my report eligible to enter into the microsoft hall of fame program?

You would need to ask Microsoft... this is Mozilla's bug tracker, not Microsoft's.

It looks like this was set to sec-bounty- without a hof annotation (comment 10), so I think that means the answer wrt Mozilla's hall of fame is "no".

Comment 19

[Gemilang]

so my report doesn't qualify for bug bounty and hall of fame?

Comment 20

[Daniel Veditz [:dveditz]]

(In reply to Gemilang from comment #19)

so my report doesn't qualify for bug bounty and hall of fame?

It does not, as noted in comment 10. While we do want to fix stability problems, we are using our limited "Security Bug Bounty" budget to encourage research into more impactful security issues. Please see https://www.mozilla.org/en-US/security/client-bug-bounty/

Comment 21

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

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

For more information, please visit BugBot documentation.

Comment 22

[Jonathan Kew [:jfkthame]]

From a Layout point of view, this is simply "huge amounts of text take a long time to measure/render". Of course we'd always like to improve the performance, but I don't think there's a specific acute issue here.

It might still be worth trying some mitigation on the front-end side, given that we've seen this with things like massive data: URLs, and when it happens in the address bar (as opposed to arbitrary web content) it's liable to block the main process, which is more annoying that only affecting a content process.

Mark, maybe worth spinning off a front-end bug about that?

Comment 23

[Mark Banner (:standard8)]

(In reply to Jonathan Kew [:jfkthame] from comment #22)

Mark, maybe worth spinning off a front-end bug about that?

I just filed bug 1907866.

Comment 24

[Gemilang]

hi team, can i ask something, it is possible if i get cve for this?