Bug 100763 - Cairo-1.15.4 Denial-of-Service Attack due to Logical Problem in Program
Summary: Cairo-1.15.4 Denial-of-Service Attack due to Logical Problem in Program
Status: RESOLVED MOVED
Alias: None
Product: cairo
Classification: Unclassified
Component: freetype font backend (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: David Turner
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-04-23 15:11 UTC by Jiaqi Peng
Modified: 2018-08-25 13:34 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
detailed analysis report, a poc file, proposed patch (1.39 MB, application/zip)
2017-04-23 15:11 UTC, Jiaqi Peng
Details
unencrypted_report_and_poc (1.40 MB, application/zip)
2017-05-04 11:53 UTC, Jiaqi Peng
Details
proposed patch (550 bytes, patch)
2017-05-04 17:38 UTC, Antonio Larrosa
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Jiaqi Peng 2017-04-23 15:11:52 UTC
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
Comment 1 Jiaqi Peng 2017-04-24 14:19:45 UTC
Hello,

RedHat suggests me to use CVE-2017-7475 for this issue. Could you take time to confirm this bug?
Comment 2 Jiaqi Peng 2017-05-04 06:34:33 UTC
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 :)
Comment 3 Jiaqi Peng 2017-05-04 11:53:31 UTC
Created attachment 131198 [details]
unencrypted_report_and_poc

This is the unencrypted report and poc.
Comment 4 Chris Wilson 2017-05-04 12:09:12 UTC
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.
Comment 5 Jiaqi Peng 2017-05-04 16:00:51 UTC
(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.
Comment 6 Antonio Larrosa 2017-05-04 17:38:16 UTC
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.
Comment 7 GitLab Migration User 2018-08-25 13:34:58 UTC
-- 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.