[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5b7eb7b2.1c69fb81.6b98e.519f@mx.google.com>
Date: Thu, 23 Aug 2018 15:33:33 +0200
From: Leonardo Taccari <iamleot@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default?
Hello Bob,
Bob Friesenhahn writes:
> You are missing something. While they are unlikely to be triggered by
> default (but still could be triggered by an attacker with sufficient
> control), testing shows that
>
> convert -verbose PS2:file.ps outfile.png
> convert -verbose file.ps2 outfile.png
> convert -verbose PS3:file.ps outfile.png
> convert -verbose file.ps3 outfile.png
>
> does in fact invoke Ghostscript.
Whoops, I stand corrected, sorry for the incorrect information!
(at least when invoking them with the `PS2:' or `PS3:' prefixes,
anyway, yes, both PS2 and PS3 policy rules are worth to be added
as well).
(Regarding the `file.ps2' and `file.ps3' examples without `PS2:' or
`PS3:' prefixes according `convert -debug Policy -log "%e"' it seems
that they ends up as:
Domain: Coder; rights=Read; pattern="PS" ...
...so should be blocked by the workaround described in
VU#332928. But please correct me if I'm wrong.)
JFTR, not related to PS2 and PS3 but also a possible ghostcript
consumer: EPT seems to ends up as `pattern="PS"' too (unlike PS2
and PS3).
Thank you!
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.
