Re: ghostscript: bypassing executeonly to escape -dSAFER sandbox (CVE-2018-17961)

[Doran Moppert <dmoppert () redhat com>]

Given the number of eyes & hours on these issues my question has to be 
naive, so I apologise, but couldn't seccomp provide a safe "safe mode" 
relatively easily?  What syscalls does legit ghostscript need once the 
input and output streams are open?

On Tue, Oct 09, 2018 at 06:34:23PM -0400, Alex Gaynor wrote:
> Would they consider making a build-time "safe PS only" flag that ensured it
> was compiled without things like shell-invocation? Then we could just try
> to convince Linux distros to package it that way :-)
>
> Alex
>
> On Tue, Oct 9, 2018 at 6:33 PM Tavis Ormandy <taviso () google com> wrote:
>
> > On Tue, Oct 9, 2018 at 3:27 PM Perry E. Metzger <perry () piermont com>
> > wrote:
> >
> > > I keep wondering if there isn't a way to fully remove the dangerous
> > > bits from a postscript interpreter so it can _only_ be used to view
> > > the document and literally has no file system access compiled in at
> > > all, so there's no way to touch the fs etc. regardless of what flags
> > > the interpreter is invoked with.
> > >
> > > (I, too, find removing the ability to look at historical postscript
> > > documents a bit more draconian than I like.)
> > >
> > >
> > I've discussed it with upstream, it's a hard no because they feel it would
> > make ghostscript non-conforming (i.e. non-conforming with the Adobe
> > PostScript Language Reference Manual)
> >
> > We probably have similar thoughts on this, but that is the final word from
> > upstream.
> >
> > Tavis.

--
Doran Moppert
Red Hat Product Security