Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.GSO.2.20.1605270933490.4552@freddy.simplesystems.org>
Date: Fri, 27 May 2016 09:37:38 -0500 (CDT)
From: Bob Friesenhahn <bfriesen@...ple.dallas.tx.us>
To: oss-security@...ts.openwall.com
Subject: Security issues addressed in GraphicsMagick SVG reader

===========================================
SVG Security Improvements in GraphicsMagick
===========================================

This is a summary of security improvements made to development
GraphicsMagick's SVG reader since the 1.3.23 release.  These
improvements were made in response to fuzz testing by Gustavo Grieco
(using Quickfuzz) which and which resulted in CVE-2016-2317 and
CVE-2016-2318.  We are thankful that Gustavo has been willing to
continue fuzz testing as improvements have been made.

While several implementation flaws were found and fixed, the most
serious issue which has been addressed is that the SVG reader was
doing no parameter value validation whatsoever.  Some algorithms are
unstable given improper inputs (e.g. negative number).  Luckily, the
SVG specification is very helpful with noting parameters which have
restricted value ranges and this can be used as a guide.

The SVG renderer in GraphicsMagick (and the built-in SVG renderer in
ImageMagick from which it originated) are based on a design where a
SVG pre-processor translates from SVG XML syntax into a simpler
internal textual form known as Magick Vector Graphics (MVG).  In most
cases the pre-processor acts as a translator/re-formatter, but in some
cases (e.g. for viewbox and affine transformations) it performs
computations.  Validation checks are added to the SVG pre-processor
whenever a value is used by computations.  Otherwise validation checks
are primarily added at the MVG level.

These improvements were made:

* Validate that parameter token text was actually consumed and that
   the token text does not overflow its buffer.

* Correctly estimate memory requirements required by the
   roundRectangle primitive.

* Validate stroke path arguments.  In particular, reject negative
   length values.

* Validate stroke dash pattern arguments.  In particular, reject
   negative length values.

* Validate stroke-miterlimit values (must be >= 1.0)

* Validate radialGradient angle values.

* Check rectangle arguments for appropriate ranges (e.g. reject
   negative width/height).

* Check rounded rectangle arguments for appropriate ranges
   (e.g. reject negative width/height/radius).

* Check ellipse arguments for appropriate range (e.g. reject negative
   radius).

* Check viewbox arguments for appropriate ranges (e.g. reject negative
   width/height).

* Prohibit use of Magick-specific file name prefixes and suffix
   arguments in SVG URLs.

* Limit the allowed size of clip-path and gradient images.

* Added drawing recursion detection.  This avoids hangs and stack
   exhaustion given self-referential URLs in the SVG.

* Fix usages of uninitialized memory discovered with some SVG files.


Fuzz testing is an on-going process and we will continue to address
any issues discovered.

Bob
-- 
Bob Friesenhahn
bfriesen@...ple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.