1246093 - (CVE-2016-1523) Several security patches for the graphite library are not backported to firefox esr 38

Status: RESOLVED FIXED

(Core :: Graphics: Text, defect)

Description

[Holger Fuhrmannek]

Attachment: poc.zip

For example a slightly different version of Bug 1223002 (wrong processing of cntxt_item interstructions) which is fixed in autumn 15 is still exploitable in ff esr 38.6.
I think despite ff esr 38 is near eol this is interesting because some bugs of this kind are really powerful.
For example my poc spawns a calc.exe in the current ff esr 38.6 with win32 bit (full aslr+dep bypass).

Comment 1

[Holger Fuhrmannek]

ff 38.6 has graphite 1.2.4 (from 2014). I guess no patch for 1.3 was backported.

Comment 2

[Daniel Veditz [:dveditz]]

Thanks for the PoC. We saw the Talos advisories Friday and noted this. Don't know if we filed a bug yet--our first task was verifying the mainline versions.

We should just upgrade graphite on ESR-38, not try to figure out which fixes were security fixes and hope we got all the non-security patches the security patches assumed were already there.

Comment 3

[Jonathan Kew [:jfkthame]]

Attachment: Update graphite2 library to latest release on esr38

Patch for esr38 only; this updates graphite2 to the latest upstream code, in effect a roll-up of all the graphite2 updates that we've taken on trunk over the past several months.

Comment 4

[Jonathan Kew [:jfkthame]]

Comment on attachment 8717335 [details] [diff] [review]
Update graphite2 library to latest release on esr38

Rubber-stamping this with r=me. I'm going to assert that this patch doesn't really need any further "review" in the usual sense, as it's simply applying the same library version to esr38 as we're already using elsewhere. Whether to land this (on esr38 only) isn't a code review question, it's a security risk vs code churn decision.


[Security approval request comment]
How easily could an exploit be constructed based on the patch?
It's publicly known there are flaws in the older library version, whereby malicious/corrupted fonts may trigger out-of-bounds accesses or other problems. It's unclear how easily this could be translated to an actual exploit, but given the recent press attention, we should assume someone might try.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
No, this is a general update of the library version. (But anyone familiar with flaws in older graphite2 releases would obviously realize they may be applicable to versions prior to this update.)

Which older supported branches are affected by this flaw?
n/a

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?
n/a, this is for esr38 only

How likely is this patch to cause regressions; how much testing does it need?
Minimal regression risk, this is just updating the lib to the same version we're using on the main channels.

Comment 5

[Al Billings [:abillings - ex-MoCo]]

I'm happy to give sec-approval. I haven't given it since this is ESR38 only and I really need to know what the ESR38 approval story is from release management first.

Comment 6

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8717335 [details] [diff] [review]
Update graphite2 library to latest release on esr38

Let's take it for an esr Chemspill

Comment 7

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/releases/mozilla-esr38/rev/ba41d4bd44a2

Comment 8

[Liz Henry (:lizzard) (relman/hg->git project)]

OK, i'm starting a build now for 38.6.1esr. We will aim to ship this on Thursday morning. Thanks Jonathan.

Comment 9

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Landed on a relbranch so this is the only thing going in to esr38.6.1:
https://hg.mozilla.org/releases/mozilla-esr38/rev/ed4d2ce6046b

Comment 10

[Cornel Ionce [:noni] [Hubs QA]]

Reproduced this issue with the attached poc on Windows 10x86 using 38.6.0 ESR, build ID 20160120213330.

Confirming this no longer reproduces with ESR 38.6.1, build ID 20160210125511.

Comment 11

[Liz Henry (:lizzard) (relman/hg->git project)]

Thank you Cornel!
Fixing the esr tracking flag to be 44+ not 45. 
I think we can call this fixed now.