Created attachment 130989 [details] detailed analysis report, a poc file, proposed patch ## Overview I and my colleague have found a vulnerability of Cairo-1.15.4 when fuzzing HarfBuzz with AFL. HarBuzz is an OpenType text shaping engine and it contains a tool named hb-view which utilizes Cairo to give a graphical view of text using a font provided by user. This vulnerability is due to logical problem in program, and can cause a Denial-of-Service attack with a crafted font file. The attachment is a zip file which includes my detail analysis report and a PoC file. In order to avoid disclosing it before patch is released, I have encrypted it. The developers can communicate with me to get the password. ## Author name: Jiaqi Peng, Bingchang Liu @VARAS of IIE email: pjqruc@gmail.com
Hello, RedHat suggests me to use CVE-2017-7475 for this issue. Could you take time to confirm this bug?
Hello again, I have disclosed the issue on oss-security mailing list. And now the CVE item can be searched from MITRE: http://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-7475 Please take time to check this bug :)
Created attachment 131198 [details] unencrypted_report_and_poc This is the unencrypted report and poc.
That was a lot of rigmarole where the simple gdb bt would suffice. Issue stems from commit 79d975f84bcc32e91db517d71a7312e2e1d653d4 Author: Behdad Esfahbod <behdad@behdad.org> Date: Wed Sep 12 17:45:11 2007 -0400 [cairo-ft-font] Ignore FT_Load_Glyph errors other than out-of-memory Same for FT_Render_Glyph. When the user asks us to render a glyph that is not available in the font, it's mostly an unavoidable kind of error for them, as in, they can't avoid such a call. So it's not nice to put cairo_t in an error state and refuse any further drawying. Many PDF files are created using buggy software and cause such glpyh-not-fou nd errors for CID 0 for example. Eventually we should propagate these kind of errors up and return it from the function call causing it, but that needs API change to add return value to all text functions, so for now we just ignore these errors.
(In reply to Chris Wilson from comment #4) > That was a lot of rigmarole where the simple gdb bt would suffice. > > Issue stems from commit 79d975f84bcc32e91db517d71a7312e2e1d653d4 > Author: Behdad Esfahbod <behdad@behdad.org> > Date: Wed Sep 12 17:45:11 2007 -0400 > > [cairo-ft-font] Ignore FT_Load_Glyph errors other than out-of-memory > Same for FT_Render_Glyph. > > When the user asks us to render a glyph that is not available in the > font, > it's mostly an unavoidable kind of error for them, as in, they can't > avoid such a call. So it's not nice to put cairo_t in an error state and > refuse any further drawying. > > Many PDF files are created using buggy software and cause such > glpyh-not-fou > nd > errors for CID 0 for example. > > Eventually we should propagate these kind of errors up and return it from > the function call causing it, but that needs API change to add return > value > to all text functions, so for now we just ignore these errors. I have sensed that you already make some consideration about the error propagation. However the solution taken now really will cause some unexpected results, such as the upper application using cairo may crash. I report and disclosure this issue, so that the upper developers can pay some attention to this problem and take some defense measures as soon as possible.
Created attachment 131213 [details] [review] proposed patch I tested that this patch fixes the problem. It also can be fixed with better error propagation as stated previously, but in any case, I think it's sane to check for NULL before using memcpy.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/80.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.