[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 5 Sep 2018 20:37:19 -0400
From: "Perry E. Metzger" <perry@...rmont.com>
To: Stuart Gathman <stuart@...hman.org>
Cc: oss-security@...ts.openwall.com
Subject: Re: Re: More Ghostscript Issues: Should we disable
PS coders in policy.xml by default?
On Wed, 5 Sep 2018 15:13:53 -0400 Stuart Gathman <stuart@...hman.org>
wrote:
> On 09/05/2018 03:01 PM, Perry E. Metzger wrote:
> > I haven't been following the bugs in depth (just noticing the
> > continuous stream of them arriving), but is the issue security
> > flaws in just -dSAFER or is it overall security bugs? If it's the
> > former, given how few things actually need any of the features
> > past what -dSAFER offers, perhaps compiling the code by default
> > without any such capabilities would work well? You can't run what
> > isn't there.
>
> Postscript is a general purpose programming language. It can do
> anything to your system that a C or Python program could. The SAFER
> sandbox was supposed to be able to prevent untrusted postscript code
> from doing serious damage. But this series of bugs shows that the
> sandbox is very flawed, and running untrusted postscript relying
> only on the SAFER sandbox is a very bad idea.
I know it's a general purpose language, but if you ifdef out *all* the
IO (except to the page) and all system calls and the like from the
implementation, there's limits to what it can do. As it stands the
implementation has all those capabilities in the code, but does
anything anyone cares about actually need any of them under any
normal circumstances? If not, they can just be removed, which is a
lot easier to audit than a sandbox.
Perry
--
Perry E. Metzger perry@...rmont.com
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.
