Mike, can you please update the system freetype library. Thanks!

Jungshik Shin has been handling freetype in the past

Well, it's not likely that this won't affect CrOS becaus there is no type1 font on CrOS. 

Just in case, I'll check if the code in question affect CFF fotns we do have on CrOS. 

We had quite a few bugs in freetype as part of OSS-Fuzz testing on trunk. Many were regressions, but i think some were stable too. Can we update to tip-of-tree trunk for chromium or is it too risky?

https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1&q=label%3AProj-freetype2+Type%3DBug-Security+&sort=&groupby=&colspec=ID+Type+Component+Status+Proj+Reported+Owner+Summary+Labels&nobtn=Update

AFAIK, only Type 1 fonts were affected by old bugs, causing CVE-2017-8105 and CVE-2017-8287.

WontFixing based on c#9. Jungshik, feel free to reopen if you feel it affect CFF fonts at all.

we link chrome and ghostscript (printing) against the system freetype.  just because we don't have certain fonts in the rootfs, can't users still feed their own fonts through ?

Mike, you're right. I meant to come back to mention ghostscript, but still I don't see how external type1 fonts can be fed. Note that Blink (and Skia) does not support type1 font in web pages (Blink/Skia only support TTF/OTF including their variable font and CBDT/CBLT color font on Linux/Chrome OS). 

 Hmm,,, can a Chrome extension feed PS type1 fonts to ghostscript?  Do we have such a mechanism? 

Aha... another possibility is to make a PDF file with a malicious type 1 font embedded. Hmm. that's more realistic than a Chrome extension scenario. 

As for comment 8, up to  bug oss-fuzz:509  in the list is fine (CrOS FreeType was patched up).  

 bug oss-fuzz:738 ,  bug oss-fuzz:739 ,  bug oss-fuzz:759  are all variable font-related. We don't have any VF, yet on rootfs, but I guess they can be used as a web font. So, we have to worry about them. 

  bug oss-fuzz:935 ,  bug oss-fuzz:941  are again about PS type1 fonts. A PDF file with a malicious type 1 embedded can be an issue here. 


 bug oss-fuzz:1034  is about auto hinting that we apply for all web fonts. 

I'm upgrading FreeType to 2.8 ( https://chromium-review.googlesource.com/506850 ) for ToT. 

We can either take FT 2.8 to earlier milestones (M58) or cherry-pick fixes for the above bugs.  

 

thakis@:  how is an embedded Type 1 font handled by pdfium in Chrome?  

Does pdfium in Chrome on Linux/CrOS use a system FreeType (as of M58)?  
 

thestig: Does chrome/linux use system freetype, or a bundled one?

ooops. I meant thestig@ (sorry and thanks, thakis@ ! ). 

halcanary@ for SkiaPDF. I'm not sure of the relation between Skia PDF and pdfium. Anyway, based on the discussion in  bug 696356  (Skia PDF uses the system FreeType on Linux/CrOS), I think a malicious type 1 font embedded in PDF can be an issue in Skia PDF. 

System Freetype for M58. See https://pdfium.googlesource.com/pdfium/+/chromium/3029/pdfium.gni#12 and https://pdfium.googlesource.com/pdfium/+/chromium/3029/BUILD.gn#206

Thanks, Lei !

 bug oss-fuzz:1034   turned out to be irrelevant because it's a bug in the auto-hinting code for a newly supported script. 

For all others, I made a combined patch (simple cherry-picking does not work for some of commits). Android needs one, too (Android system freetype was exactly at the same hash as CrOS Freetype). 

If we want this to be in M58, I may as well make another CL to apply the aforementioned combined patch.  We can land that one first before in ToT updating FreeType to 2.8. That way, merging to branches can be simpler.

https://chromium-review.googlesource.com/c/507050/ does what I talked about in comment 19. 

Abhishek, sorry that I didn't think of a couple of  scenario (where exploiting this an other bugs in oss-fuzz is possible). It'd require a carefully crafted PDF with a malicious type 1 font embedded. Another possibility is to use a malicious variable font as a web font.  See comment 13 and comment 19. 

Based on those comments and M59 schedule (stable at the end of May ~ early June), would you recommend merging a fix to M58 ? 


Question to Bernie (bhthompson) :   

If we decide that this bug need to be fixed in M58, which merge-request are you more willing to take for CrOS 58.x ? 

1. https://chromium-review.googlesource.com/c/507050 : cherry-pick of 5 commits from the upstream to fix this and related bugs 
( https://chromium-review.googlesource.com/c/507035 : cherry-picking the above master CL to R58 )

2.  https://chromium-review.googlesource.com/506850  : FreeType update to 2.8 (released a few days ago) from FreeType 2.7.1 + a giant patch (mid-February )

FYI, Android O-to-be takes the first approach. 

I don't think this needs to be merged to M58. Mattias?

In general I think we should go with the smallest solution for a late stable, so option 1 seems best?

If we do want to go forward with this we should land today, we should do our last stable build for 58 this afternoon.

Thanks, Jorge and Bernie

Given Jorge's reply (I guess it's a bit too late to hear back from Mattias) and M58 schedule (a CL has to land now),  I'll leave alone M58. 

For M59, I think we can take FreeType 2.8 after a few days' baking on ToT. 

Has the uprev landed on ToT?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/a81623747d0e78c88e9744e4bcee0f3d8c413270

commit a81623747d0e78c88e9744e4bcee0f3d8c413270
Author: Jungshik Shin <jshin@chromium.org>
Date: Fri May 19 23:23:37 2017

Update FreeType to 2.8 from 2.7.1+patches (e432ebf)

A few notable changes include:

 - Autohinting support for a number of "small" scripts
 - Variable font support fixes (e.g. MVAR/HVAR/VVAR handling, CFF2,
   instance namining)
 - Sanitizer issue fixes
 - Allow linear scaling for unhinted rendering ( crbug.com/696356 )

The first one will allow us to use autohints for more fonts.

Changlog:

https://chromium.googlesource.com/chromium/src/third_party/freetype2/+log/e432ebf..a12a344

BUG= chromium:722589 , chromium:696356 , chromium:716995 
TEST=emerge-{x86-alex,amd64-generic,daisy} freetype succeeds.
TEST=cbuildbot chromiumos-sdk
TEST=cbuildbot  amd64-generic-full x86-generic-full arm-generic-full
TEST=manual/visual: WebUI rendering and web page rendering do not have any noticeable regression. (they can be slightly different).

Change-Id: I08504ddf568ce0cb2e73fe05c4013ebd92dc3240
Reviewed-on: https://chromium-review.googlesource.com/506850
Commit-Ready: Jungshik Shin <jshin@chromium.org>
Tested-by: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[delete] https://crrev.com/e523e17f5f8eb48bb5f2482dd4a11d807c377916/media-libs/freetype/files/freetype-2.7.1-ttnames.patch
[rename] https://crrev.com/a81623747d0e78c88e9744e4bcee0f3d8c413270/media-libs/freetype/freetype-2.8.ebuild
[delete] https://crrev.com/e523e17f5f8eb48bb5f2482dd4a11d807c377916/media-libs/freetype/freetype-2.7.1-r1.ebuild
[modify] https://crrev.com/a81623747d0e78c88e9744e4bcee0f3d8c413270/media-libs/freetype/Manifest
[delete] https://crrev.com/e523e17f5f8eb48bb5f2482dd4a11d807c377916/media-libs/freetype/files/freetype-2.7.1-e432ebf.patch
[add] https://crrev.com/a81623747d0e78c88e9744e4bcee0f3d8c413270/media-libs/freetype/freetype-2.8-r1.ebuild

It took a few tries with CQ before it's landed in ToT. 
I'll ask for merge to 59 after a couple of days. 

The NextAction date has arrived: 2017-05-26

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot