oss-sec mailing list archives
Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default?
From: Alex Gaynor <alex.gaynor () gmail com>
Date: Tue, 21 Aug 2018 11:21:15 -0400
A small note. Both ImageMagick and GraphicsMagick process various file formats that can nest a different image file inside of them. These are very frequently implemented with a call to ReadImage(), with no checking that it's the expected file format. (As a result, the fuzzer finds various impressive chains, with sometimes 3 different image formats nested inside of each other). The conclusion of this is that people _must not_ attempt to do their own format detection and then pass the data to IM/GM, because this can be bypassed with nested formats. It's imperative that GS truly be disabled with either policy.xml or by uninstall GS. Alex On Tue, Aug 21, 2018 at 11:01 AM Bob Friesenhahn < bfriesen () simple dallas tx us> wrote:
On Tue, 21 Aug 2018, Tavis Ormandy wrote:I think those thumbnails should be disabled, but you've probably noticedIthink everything related to untrusted ghostscript should be disabled :-)I have posted to the GraphicsMagick Announcements mailing list regarding your findings (with a link to this list) and suggested that a fool-proof solution is that Ghostscript should be uninstalled. Uninstalling Ghostscript entirely might cause software using libgs to not execute at all unless a stub library is put in its place. Dependencies on Ghostscript are much larger than one would initially think due to Postscript being the traditional output from Unix software for "printing" and thus it is used as an intermediate format in order to convert between formats. EPS content is also embedded in some other formats. Bob -- Bob Friesenhahn bfriesen () simple dallas tx us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
-- All that is necessary for evil to succeed is for good people to do nothing.
Current thread:
- More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Tavis Ormandy (Aug 21)
- Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Tavis Ormandy (Aug 21)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Bob Friesenhahn (Aug 21)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Alex Gaynor (Aug 21)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Tavis Ormandy (Aug 21)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? AmitB (Aug 22)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Bob Friesenhahn (Aug 22)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Tavis Ormandy (Aug 22)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Leonardo Taccari (Aug 23)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Mateusz Lenik (Aug 23)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Leonardo Taccari (Aug 23)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Bob Friesenhahn (Aug 23)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Leonardo Taccari (Aug 23)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Bob Friesenhahn (Aug 23)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Bob Friesenhahn (Aug 21)
- Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Tavis Ormandy (Aug 21)