File: ./5715.ttf Top Mode: Replace Sub Mode: Table Spread Table: b'Sill' Number of values: 2 Offset: 83/0x000053 Value: ['01'] Offset: 99/0x000063 Value: ['80', '00', '00', '00'] Table: b'Silf' Number of values: 4 Offset: 12406/0x003076 Value: ['40', '00'] Offset: 12691/0x003193 Value: ['00', '00', '00', '00'] Offset: 87327/0x01551f Value: ['00', '00'] Offset: 182235/0x02c7db Value: ['80', '00', '00', '00']
Update to latest rev from upstream, to pick up fix for this bug. (See changelog at http://hg.palaso.org/graphitedev for more details.)
Attachment #674410 - Flags: review?(jdaggett)
Comment on attachment 674410 [details] [diff] [review] update graphite2 lib to upstream commit 4ddfa0f51098 https://hg.mozilla.org/integration/mozilla-inbound/rev/f3a713569db5 Argh... sorry, guys, I remembered about the new sec-approval flag & process right AFTER pushing this to inbound. :( Marking sec-approval? now (after the horse has bolted), so as to bring it to your attention anyway. [Security approval request comment] How easily can the security issue be deduced from the patch? It's an import of a library, so the obvious conclusion is that it fixes a flaw in that lib. Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem? The individual commits (available in upstream's repository) that are part of the update could help someone figure out how to craft a corrupted font that might crash the browser, as they indicate the specific places where checks were added. Which older supported branches are affected by this flaw? Possibly as far back as mozilla-11, when the graphite2 lib first landed (bug 631479). If not all supported branches, which bug introduced the flaw? Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be? Older branches already have older versions of the graphite2 library - and so may have additional unpatched issues. (Our most recent update was in bug 797863, but this is only on trunk.) Backporting the complete library update would be pretty simple, though for branches not already on v1.2, it'd be a large patch. How likely is this patch to cause regressions; how much testing does it need? Unlikely; the changes are mainly tightening of bounds checks in obscure places, only hit when loading corrupted font tables. One last point: note that this entire feature is preffed-off by default, so there is no risk exposure (on any branch) unless a user has explicitly enabled it in about:config. If you want to land this on older branches, I'll prepare branch patches accordingly; personally, though, I'm not sure it's worth the effort/churn to do this for a preffed-off feature.
Attachment #674410 - Flags: sec-approval?
Comment on attachment 674410 [details] [diff] [review] update graphite2 lib to upstream commit 4ddfa0f51098 "The dog? He left me." Approving after the fact. :-)
Attachment #674410 - Flags: sec-approval? → sec-approval+
(In reply to Jonathan Kew (:jfkthame) from comment #3) > One last point: note that this entire feature is preffed-off by default, so > there is no risk exposure (on any branch) unless a user has explicitly > enabled it in about:config. Given that, wontfixing for ESR17.
Per Jonathan, this is disabled in 18 behind a pref so not a default security issue there.
You need to log in before you can comment on or make changes to this bug.