[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181017061446.GM5150@brightrain.aerifal.cx>
Date: Wed, 17 Oct 2018 02:14:46 -0400
From: Rich Felker <dalias@...c.org>
To: oss-security@...ts.openwall.com
Cc: Perry Metzger <perry@...rmont.com>
Subject: Re: ghostscript: 1Policy operator gives access to
.forceput CVE-2018-18284
On Tue, Oct 16, 2018 at 01:33:32PM -0700, Tavis Ormandy wrote:
> On Tue, Oct 16, 2018 at 12:57 PM Perry E. Metzger <perry@...rmont.com>
> wrote:
>
> > On Tue, 16 Oct 2018 11:06:14 -0700 Tavis Ormandy <taviso@...gle.com>
> > wrote:
> > > Side note: I'm done looking at ghostscript for now, but still
> > > *strongly* recommend that we deprecate untrusted postscript and
> > > disable ghostscript coders by default in policy.xml.
> >
> > Again, given that PostScript is an archival format for a lot of
> > documents, wouldn't a version of ghostscript with all the ability to
> > do anything dangerous removed from the interpreter at compile time be
> > rational?
> >
> >
> We have to work with what we've got.
>
> Even with the easy to exploit stuff compiled out (which upstream do not
> support), I haven't been bothering to get CVE's for all the memory
> corruption or UaF I've been reporting, because nobody can keep up with
> these operator leaks anyway.
An obvious fix for UaF's would be just removing the frees. Use of gs
as an interactive program where leaks would matter is a historical
curiosity; the only meaningful modern use is as a converter.
If someone insists there are still uses where freeing matters,
something like talloc may be a reasonable solution, removing all the
internal frees and only performing frees of the whole context.
Rich
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.
