1601851 - @ OOM | large | NS_ABORT_OOM | nsTArray_base<T>::EnsureCapacity<T> | gfxTextRun::GetAdvanceWidth

Status: RESOLVED FIXED

(Core :: Graphics: Text, defect)

Description

[Kexu Wang]

Attachment: ruby-crash-poc.zip

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

Steps to reproduce:

1. Open the PoC "poc.html" with Firefox
2. Click "TriggerCrash" button

Actual results:

Output box will show "FF FF FF FF FF FF FF FF FF FF FF FF FF... "

Expected results:

Firefox Crashed

Comment 1

[Kexu Wang]

crash reportid : bp-1c6fa275-b258-429a-9247-fe7c80191206

Comment 2

[:Gijs (he/him)]

Attachment: Minimal crash PoC

More minimal crash PoC that doesn't involve a ~240mb string embedded in a JS file.

Comment 3

[:Gijs (he/him)]

I don't know why we're allocating a ~3.8gb thing here. It's an OOM crash so it's not super terrible (probably doesn't need to be security sensitive) but the string is "only" ~240mb characters, so unsure why the allocation becomes so big. Jonathan, are you the right person to look at this?

Comment 4

[Jonathan Kew [:jfkthame]]

Because the 240M-character string is inside <ruby>, we suppress line-breaking for it, and try to measure it as a single line of text. This involves getting the spacing values for each character, which go into an array of doubles, two per character (for spacing before/after). So that's a buffer of 16 bytes per character of the text. 16 * 240M = 3.8G. Boom.

Maybe we can do things to avoid or at least reduce this, but it won't really make much difference; this is essentially a version of the eternal report that says "dump an ever-increasing amount of content into the DOM and eventually something will break". If not the spacing buffer, then the glyph data array in the textrun (4 bytes per character), or something. As long as we fail safely, it's not a big concern.

Comment 5

[Jonathan Kew [:jfkthame]]

One thing we can do here, I think, is to use fallible allocation for the spacing array, so that if it's ridiculously large, we just fail to allocate it, and any spacing (letter-spacing, word-spacing, tabs, etc) won't be measured/drawn properly, but at least we shouldn't crash. No realistic use-case is likely to care about details of spacing on a multi-megacharacter line of text anyhow.

It looks like this code was originally written assuming fallible allocation, as it checks the AppendElements() calls for failure, but when nsTArray was made infallible by default, we didn't update these callsites to remain fallible. So let's fix that, and at least this specific crash should no longer happen. (But it will remain possible to crash the content process by variations of this kind of thing, I'm sure; it'll just run out of memory somewhere else if not here.)

Comment 6

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1601851 - Use fallible allocation for Spacing arrays in gfxTextRun. r=lsalzman

Comment 7

[Jonathan Kew [:jfkthame]]

As a safe OOM crash, I don't think any particular security severity rating is applicable here; just marking as csectype-oom.

Comment 8

[Jonathan Kew [:jfkthame]]

Gijs, any reason not to unhide this? AFAICS it's not a sec risk, just an OOM crash.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/444ce4d8dbe5
Use fallible allocation for Spacing arrays in gfxTextRun. r=lsalzman

Comment 10

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/444ce4d8dbe5

Comment 11

[Kexu Wang]

Hi Mozilla,

I reported a Bug with id 1601851 on 2019/12/05. This bug was fixed on 2019/12/07.
I think this is a security vulnerability because it is a denial of service attack. Can you add my credit information to your Security Advisories?

Please add my credit information following:
This vulnerability was discovered by Kexu Wang of Fortinet's FortiGuard Labs.

Comment 12

[Andrew McCreight [:mccr8]]

Sorry, we usually don't issue security advisories for safe out of memory crashes. Due to the nature of a web browser, there are many ways to cause it to run out of memory. If you have more questions about this, you can email [e-mail] .