Ubuntu has issued an advisory today (August 28): https://usn.ubuntu.com/usn/usn-3403-1/ Mageia 5 and Mageia 6 are also affected.
Whiteboard: (none) => MGA6TOO, MGA5TOO
Assigning to all packagers collectively, since there is no registered maintainer for this package. CC'ing some committers.
CC: (none) => anaselli, lmenut, mageia, mageia, marja11, olavAssignee: bugsquad => pkg-bugs
Suggested advisory: ======================== The updated packages fix security vulnerabilities: The Ins_MIRP function in base/ttinterp.c in Artifex Ghostscript GhostXPS 9.21 allows remote attackers to cause a denial of service (heap-based buffer over-read and application crash) or possibly have unspecified other impact via a crafted document. (CVE-2017-9611) The Ins_IP function in base/ttinterp.c in Artifex Ghostscript GhostXPS 9.21 allows remote attackers to cause a denial of service (use-after-free and application crash) or possibly have unspecified other impact via a crafted document. (CVE-2017-9612) The Ins_MDRP function in base/ttinterp.c in Artifex Ghostscript GhostXPS 9.21 allows remote attackers to cause a denial of service (heap-based buffer over-read and application crash) or possibly have unspecified other impact via a crafted document. (CVE-2017-9726) The gx_ttfReader__Read function in base/gxttfb.c in Artifex Ghostscript GhostXPS 9.21 allows remote attackers to cause a denial of service (heap-based buffer over-read and application crash) or possibly have unspecified other impact via a crafted document. (CVE-2017-9727) The Ins_JMPR function in base/ttinterp.c in Artifex Ghostscript GhostXPS 9.21 allows remote attackers to cause a denial of service (heap-based buffer over-read and application crash) or possibly have unspecified other impact via a crafted document. (CVE-2017-9739) The gs_alloc_ref_array function in psi/ialloc.c in Artifex Ghostscript 9.21 allows remote attackers to cause a denial of service (heap-based buffer overflow and application crash) or possibly have unspecified other impact via a crafted PostScript document. This is related to a lack of an integer overflow check in base/gsalloc.c. (CVE-2017-9835) psi/ztoken.c in Artifex Ghostscript 9.21 mishandles references to the scanner state structure, which allows remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact via a crafted PostScript document, related to an out-of-bounds read in the igc_reloc_struct_ptr function in psi/igc.c. (CVE-2017-11714) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9611 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9612 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9726 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9727 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9739 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9835 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11714 ======================== Updated packages in 5/core/updates_testing: ======================== ghostscript-9.20-1.1.mga5 ghostscript-dvipdf-9.20-1.1.mga5 ghostscript-common-9.20-1.1.mga5 ghostscript-X-9.20-1.1.mga5 ghostscript-module-X-9.20-1.1.mga5 lib(64)gs9-9.20-1.1.mga5 lib(64)gs-devel-9.20-1.1.mga5 lib(64)ijs1-0.35-115.1.mga5 lib(64)ijs-devel-0.35-115.1.mga5 ghostscript-doc-9.20-1.1.mga5 from SRPMS: ghostscript-9.20-1.1.mga5.src.rpm Updated packages in 6/core/updates_testing: ======================== ghostscript-9.20-3.1.mga6 ghostscript-dvipdf-9.20-3.1.mga6 ghostscript-common-9.20-3.1.mga6 ghostscript-X-9.20-3.1.mga6 ghostscript-module-X-9.20-3.1.mga6 lib(64)gs9-9.20-3.1.mga6 lib(64)gs-devel-9.20-3.1.mga6 lib(64)ijs1-0.35-122.1.mga6 lib(64)ijs-devel-0.35-122.1.mga6 ghostscript-doc-9.20-3.1.mga6 from SRPMS: ghostscript-9.20-3.1.mga6.src.rpm
Status: NEW => ASSIGNEDCC: (none) => nicolas.salgueroAssignee: pkg-bugs => qa-bugsVersion: Cauldron => 6Whiteboard: MGA6TOO, MGA5TOO => MGA5TOO
Giving this a look for mga6, then maybe mga5. The first CVE has a PoC test but needs gxps which I have not found yet. It looks like a long haul.
CC: (none) => tarazed25
The example commands for some of the PoCs look like this: $ ./gxps -sDEVICE=pdfwrite -sOutputFile=/dev/null -dNOPAUSE $FILE The gxps there looks like some local utility. There does not seem to be any system utility with that name but libgxps-tools provides /usr/bin/xpstojpeg /usr/bin/xpstopdf /usr/bin/xpstopng /usr/bin/xpstops /usr/bin/xpstosvg so my guess is that xpstopdf might apply to this context but it is not apparent what the connection is to ghostscript. A couple of the PoCs are run against gs which IS ghostscript. PDF files are essentially postscript in a wrapper and ghostscript tends to deal in postscript so maybe there is a tenuous connection.
(In reply to Len Lawrence from comment #4) > The example commands for some of the PoCs look like this: > $ ./gxps -sDEVICE=pdfwrite -sOutputFile=/dev/null -dNOPAUSE $FILE > > The gxps there looks like some local utility. There does not seem to be any > system utility with that name It is in ghostpcl $ urpmf gxps ghostpcl:/usr/bin/gxps
CC: (none) => jim
Thanks for that reference. I am adding my report to date but shall run through all the tests again with the Mageia version of gxps and note any discrepancies. ============================================================================== libgxps-tools provides /usr/bin/xpstojpeg /usr/bin/xpstopdf /usr/bin/xpstopng /usr/bin/xpstops /usr/bin/xpstosvg gxps seems to be associated with GhostPDL which is not in the Mageia repositories because it is semi-commercial. Managed to download it from https://www.ghostscript.com/download/gxpsdnld.html but it is built for Ghostscript 9.21. It is offered under the GNU Affero General Public License which can be downloaded as an HTML file. The PoCs were run before the updates as detailed below. ----------------------------------------------------------------- CVE-2017-9611 https://bugs.ghostscript.com/show_bug.cgi?id=698024 PoC is Ins_MIRP, a zip file. '[Content_Types].xml' Documents/ FixedDocumentSequence.fdseq Metadata/ _rels/ $ ./gxps -sDEVICE=pdfwrite -sOutputFile=/dev/null -dNOPAUSE $FILE before: $ gxps -sDEVICE=pdfwrite -sOutputFile=/dev/null -dNOPAUSE Ins_MIRP Segmentation fault (core dumped) ----------------------------------------------------------------- CVE-2017-9612 https://bugs.ghostscript.com/show_bug.cgi?id=698026 Ins_IP before: $ gxps -sDEVICE=pdfwrite -sOutputFile=/dev/null -dNOPAUSE Ins_IP That passed without comment - the PoC must be a dud. Running the whole command under valgrind produces a report whch says all heap blocks were freed and no leaks are possible. ----------------------------------------------------------------- CVE-2017-9726 https://bugs.ghostscript.com/show_bug.cgi?id=698055 Ins_MDRP The comments upstream indicate that the PoC does not crash if run without a debug or test harness but in fact.... before: $ gxps -sDEVICE=pdfwrite -sOutputFile=/dev/null -dNOPAUSE Ins_MDRP Segmentation fault (core dumped) ----------------------------------------------------------------- CVE-2017-9727 https://bugs.ghostscript.com/show_bug.cgi?id=698056 gx_ttfReader__Read before: $ gxps -sDEVICE=pdfwrite -sOutputFile=/dev/null -dNOPAUSE gx_ttfReader__Read ./xps/xpszip.c:185: xps_read_zip_entry(): truncated zipfile entry; possibly corrupt data Running this with valgrind showed that there were no problems with memory allocation. The upstream test aborted in the ASAN environment. ----------------------------------------------------------------- CVE-2017-9739 https://bugs.ghostscript.com/show_bug.cgi?id=698063 Ins_JMPR before: $ gxps -sDEVICE=pdfwrite -sOutputFile=/dev/null -dNOPAUSE Ins_JMPR valgrind does not provide any useful information. Upstream does not expect any problem in a non-debug environment but their ASAN test ends in an abort. ----------------------------------------------------------------- CVE-2017-9835 https://bugs.ghostscript.com/show_bug.cgi?id=697985 gs_alloc_ref_array gs -dNOPAUSE -sDEVICE=bit -sOUTPUTFILE=/dev/null -dSAFER $FILE -c quit before: GPL Ghostscript 9.20 (2016-09-26) Copyright (C) 2016 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Error: /VMerror in (binary token, type=128) VM status: 1 1764808 3055176 Current allocation mode is local GPL Ghostscript 9.20: Unrecoverable error, exit code 1 ----------------------------------------------------------------- CVE-2017-11714 https://bugs.ghostscript.com/show_bug.cgi?id=698158 gs_oobr_igc_reloc_struct_ptr $ gs -dNOPAUSE -sDEVICE=bit -sOUTPUTFILE=/dev/null -dSAFER gs_oobr_igc_reloc_struct_ptr -c quit before: GPL Ghostscript 9.20 (2016-09-26) Copyright (C) 2016 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Segmentation fault (core dumped) ----------------------------------------------------------------- So there is not a lot to go on with these PoCs. On a positive note it looks like gxps behaves itself in spite of the version mismatch. An strace on the CVE-2017-9727 test did not highlight any errors.
Re comment 5; Yes, I had forgotten urpmf. urpmq --whatprovides blanked. ghostpcl now installed and gxps is in /bin. Some of the remarks in comment 6 are now rendered false or redundant.
Another pass through the CVE PoC tests: CVE-2017-9611 before: $ gxps -sDEVICE=pdfwrite -sOutputFile=/dev/null -dNOPAUSE Ins_MIRP Segmentation fault (core dumped) ----------------------------------------------------------------- CVE-2017-9612 before: $ gxps -sDEVICE=pdfwrite -sOutputFile=/dev/null -dNOPAUSE Ins_IP Segmentation fault (core dumped) ----------------------------------------------------------------- CVE-2017-9726 before: $ gxps -sDEVICE=pdfwrite -sOutputFile=/dev/null -dNOPAUSE Ins_MDRP GPL Ghostscript 9.05: Failed to interpret TT instructions for glyph index 36 of font Algerian. Continue ignoring instructions of the font. Segmentation fault (core dumped) ----------------------------------------------------------------- CVE-2017-9727 before: $ gxps -sDEVICE=pdfwrite -sOutputFile=/dev/null -dNOPAUSE gx_ttfReader__Read GPL Ghostscript 9.05: Failed to interpret TT instructions for glyph index 36 of font Unknown. Continue ignoring instructions of the font. Segmentation fault (core dumped) Running this with valgrind also resulted in a segfault. ----------------------------------------------------------------- CVE-2017-9739 before: $ gxps -sDEVICE=pdfwrite -sOutputFile=/dev/null -dNOPAUSE Ins_JMPR GPL Ghostscript 9.05: Failed to interpret TT instructions for glyph index 55 of font Algerian. Continue ignoring instructions of the font. ----------------------------------------------------------------- CVE-2017-9835 before: $ gs -dNOPAUSE -sDEVICE=bit -sOUTPUTFILE=/dev/null -dSAFER gs_alloc_ref_array -c quit GPL Ghostscript 9.20 (2016-09-26) Copyright (C) 2016 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Error: /VMerror in (binary token, type=128) VM status: 1 1764808 3055176 Current allocation mode is local GPL Ghostscript 9.20: Unrecoverable error, exit code 1 ----------------------------------------------------------------- CVE-2017-11714 before: $ gs -dNOPAUSE -sDEVICE=bit -sOUTPUTFILE=/dev/null -dSAFER gs_oobr_igc_reloc_struct_ptr -c quit GPL Ghostscript 9.20 (2016-09-26) Copyright (C) 2016 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Segmentation fault (core dumped) ----------------------------------------------------------------- More to go on now.
Updates not on the mirrors yet and it is getting late.
Updated to ghostscript 9.20-3.1 and ran the tests again: CVE-2017-9611 after: $ gxps -sDEVICE=pdfwrite -sOutputFile=/dev/null -dNOPAUSE Ins_MIRP Segmentation fault (core dumped) ----------------------------------------------------------------- CVE-2017-9612 after: $ gxps -sDEVICE=pdfwrite -sOutputFile=/dev/null -dNOPAUSE Ins_IP Segmentation fault (core dumped) ----------------------------------------------------------------- CVE-2017-9726 after: $ gxps -sDEVICE=pdfwrite -sOutputFile=/dev/null -dNOPAUSE Ins_MDRP GPL Ghostscript 9.05: Failed to interpret TT instructions for glyph index 36 of font Algerian. Continue ignoring instructions of the font. Segmentation fault (core dumped) ----------------------------------------------------------------- CVE-2017-9727 after: $ gxps -sDEVICE=pdfwrite -sOutputFile=/dev/null -dNOPAUSE gx_ttfReader__Read GPL Ghostscript 9.05: Failed to interpret TT instructions for glyph index 36 of font Unknown. Continue ignoring instructions of the font. Segmentation fault (core dumped) Running this with valgrind also resulted in a segfault. ----------------------------------------------------------------- CVE-2017-9739 after: $ gxps -sDEVICE=pdfwrite -sOutputFile=/dev/null -dNOPAUSE Ins_JMPR GPL Ghostscript 9.05: Failed to interpret TT instructions for glyph index 55 of font Algerian. Continue ignoring instructions of the font. ----------------------------------------------------------------- CVE-2017-9835 after: $ gs -dNOPAUSE -sDEVICE=bit -sOUTPUTFILE=/dev/null -dSAFER gs_alloc_ref_array -c quit GPL Ghostscript 9.20 (2016-09-26) Copyright (C) 2016 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Error: /VMerror in (binary token, type=128) VM status: 1 1764808 3055176 Current allocation mode is local GPL Ghostscript 9.20: Unrecoverable error, exit code 1 ----------------------------------------------------------------- CVE-2017-11714 after: $ gs -dNOPAUSE -sDEVICE=bit -sOUTPUTFILE=/dev/null -dSAFER gs_oobr_igc_reloc_struct_ptr -c quit GPL Ghostscript 9.20 (2016-09-26) Copyright (C) 2016 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. ----------------------------------------------------------------- In all but the last of these the output is identical to the before tests. In the case of CVE-2017-11714 there was no segfault. In the tests using gxps it may not be surprising that the updates make no difference because gxps comes from ghostpcl which is not part of this update. Note the references to Ghostscript 9.05. However, gs does trap a segfault, in the last test. In earlier tests gs simply reports that the PoC files have errors, which is probably expected behaviour even after the patches; i.e. the patches have not interfered with existing error-trapping code. For the tests with gxps all we can say is that the PoCs trigger crashes, as they are meant to do but cannot tell us if the patches are effective, maybe because of misaligned versions of Ghostscript. Does GhostPCL need to be rebuilt?
Keywords: (none) => feedback
(In reply to Len Lawrence from comment #10) > In the tests using gxps it may not be surprising that the updates make no > difference because gxps comes from ghostpcl which is not part of this > update. Note the references to Ghostscript 9.05. However, gs does trap a > segfault, in the last test. In earlier tests gs simply reports that the PoC > files have errors, which is probably expected behaviour even after the > patches; i.e. the patches have not interfered with existing error-trapping > code. > > For the tests with gxps all we can say is that the PoCs trigger crashes, as > they are meant to do but cannot tell us if the patches are effective, maybe > because of misaligned versions of Ghostscript. Does GhostPCL need to be > rebuilt? After some verification, it appears that: 1) We have GhostPCL (in fact, GhostPDL) 9.05, which is built against its own Ghostscript 9.05 (and does not use the one from the system). 2) Upstream provides GhostPDL releases at the same time as Ghostscript ones and GhostPDL always embeds its own Ghostscript. So I think we should update to GhostPDL 9.20 plus the patches for the different CVEs already corrected in our Ghostscript 9.20 to be coherent. What is the opinion of people who updated Ghostscript in the past?
We have Ghost PCL/PDL? Where? If we do have such a thing, can it be fixed to build against system ghostscript? Otherwise, updating and patching it sounds fine.
(In reply to David Walser from comment #12) > We have Ghost PCL/PDL? Where? If we do have such a thing, can it be fixed > to build against system ghostscript? Otherwise, updating and patching it > sounds fine. We have GhostPDL in package "ghostpcl". When I tried "./configure --help" in ghostpdl-9.20 extracted from a tarball I got here: https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/download/gs920/ghostpdl-9.20.tar.gz, I saw no option to use Ghostscript from the system (only "--with-system-libtiff"). Other security problems may be expected too because GhostPDL 9.20 also embeds several other libraries that had security issues in the past (and is not using the ones from the system). Here is the output of "ls -l" command in ghostpdl-9.20: """ total 592 drwxr-xr-x 2 salguero salguero 4096 sept. 26 2016 arch/ -rwxr-xr-x 1 salguero salguero 820 sept. 26 2016 autogen.sh* drwxr-xr-x 2 salguero salguero 24576 sept. 26 2016 base/ -rwxr-xr-x 1 salguero salguero 326319 sept. 26 2016 configure* -rw-r--r-- 1 salguero salguero 80423 sept. 26 2016 configure.ac drwxr-xr-x 13 salguero salguero 4096 sept. 26 2016 contrib/ drwxr-xr-x 3 salguero salguero 4096 sept. 26 2016 cups/ drwxr-xr-x 4 salguero salguero 4096 sept. 26 2016 devices/ drwxr-xr-x 3 salguero salguero 4096 sept. 26 2016 doc/ -rw-r--r-- 1 salguero salguero 10694 sept. 26 2016 DroidSansFallback.NOTICE drwxr-xr-x 3 salguero salguero 4096 sept. 26 2016 examples/ drwxr-xr-x 12 salguero salguero 4096 sept. 26 2016 expat/ drwxr-xr-x 8 salguero salguero 4096 sept. 26 2016 freetype/ drwxr-xr-x 3 salguero salguero 4096 sept. 26 2016 gpdl/ drwxr-xr-x 2 salguero salguero 4096 sept. 26 2016 iccprofiles/ drwxr-xr-x 2 salguero salguero 4096 sept. 26 2016 ijs/ drwxr-xr-x 2 salguero salguero 4096 sept. 26 2016 jbig2dec/ drwxr-xr-x 2 salguero salguero 4096 sept. 26 2016 jpeg/ drwxr-xr-x 3 salguero salguero 4096 sept. 26 2016 jpegxr/ drwxr-xr-x 10 salguero salguero 4096 sept. 26 2016 lcms2/ drwxr-xr-x 2 salguero salguero 12288 sept. 26 2016 lib/ drwxr-xr-x 7 salguero salguero 4096 sept. 26 2016 libpng/ -rw-r--r-- 1 salguero salguero 3263 sept. 26 2016 LICENSE -rw-r--r-- 1 salguero salguero 24165 sept. 26 2016 Makefile.in drwxr-xr-x 3 salguero salguero 4096 sept. 26 2016 man/ drwxr-xr-x 3 salguero salguero 4096 sept. 26 2016 openjpeg/ drwxr-xr-x 7 salguero salguero 4096 sept. 26 2016 pcl/ drwxr-xr-x 2 salguero salguero 12288 sept. 26 2016 psi/ drwxr-xr-x 12 salguero salguero 4096 sept. 26 2016 Resource/ drwxr-xr-x 12 salguero salguero 4096 sept. 26 2016 tiff/ drwxr-xr-x 8 salguero salguero 4096 sept. 26 2016 toolbin/ drwxr-xr-x 2 salguero salguero 4096 sept. 26 2016 windows/ drwxr-xr-x 3 salguero salguero 4096 sept. 26 2016 xps/ drwxr-xr-x 14 salguero salguero 4096 sept. 26 2016 zlib/ """
Gross, and the ghostpcl package has also been unmaintained since Mageia 3 (not to mention it was never updated or fixed for security issues). I guess you can check with other distros to see if the package is in any way fixable, but for sure it should be dropped in Cauldron. Either way, it shouldn't hold up this update.
Keywords: feedback => (none)
In reply to Nicholas and David in comments 13 and 14. Thanks for looking into this and in view of your conclusions I should move this update on as there does not seem to be anything else we can do.
Utility tests for ghostscript. Viewed Postscript files with gs. Normally if I need to send a document to my wifi printer say from within a ruby script 'lpr -Pokda filename.txt' will always work and AFAIK Ghostscript is involved somewhere in the output chain. Trying to use ghostscript to access a printer directly from the command line is next to impossible because it knows nothing about the way you may have used cups or hplip to set up printer queues. Running gs you have to know beforehand exactly what parameter values to supply. I experimented, trying to guess the values, but got nowhere. The documentation would indicate that you use a command similar to this: $ gs -sDEVICE=ijs -sIjsServer=hpijs -sDeviceManufacturer=HEWLETT-PACKARD -sDeviceModel='PHOTOSMART 5520' -sOutputFile=/dev/lp2 -dNOPAUSE -- ticket.ps but this returns a cryptic message: GPL Ghostscript 9.20 (2016-09-26) Copyright (C) 2016 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. **** Unable to open the initial device, quitting. Tinkering with the values does not help - it always fails. Using the X display device is a lot simpler. The following commands work fine - the files are displayed on screen. $ gs abc-1.ps GPL Ghostscript 9.20 (2016-09-26) Copyright (C) 2016 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Loading CharterBT-Roman font from /usr/share/fonts/default/ghostscript/bchr.pfa... 4289068 2798511 4076224 2765898 3 done. >>showpage, press <return> to continue<< GS>(ticket.ps) run Loading AndaleMono font from /usr/share/fonts/default/ghostscript/andalemo.pfb... 4316700 2897919 4056024 2757173 3 done. >>showpage, press <return> to continue<< GS>(abc-1.pdf) run Processing pages 1 through 1. Page 1 >>showpage, press <return> to continue<< GS> quit Leaving this open for a while in case somebody with more expertise can throw light on using ghostscript on the commandline.
For printing that is.
Whiteboard: MGA5TOO => MGA5TOO MGA6-64-OK
@Len Trying to follow you (M5/64). First, thanks for your detective work to find the PoCs. I am puzzled how you applied the .zip PoC files to the gxps commands, for which you used the zip file basenames. If you unzip them, you get a host of files. Create a directory of the basename and unzip into that, citing the directory name as the gxps file parameter?
CC: (none) => lewyssmith
@Lewis I was puzzled also when the file was unzipped and could see no way to relate the contents to gxps. Referring back to the example in the upstream report it appeared that using the archive name is the correct way to go. Beats me though. You might be right though about treating the root directory as the file parameter. I did not try that.
$ gxps Ins_MIRP GPL Ghostscript 9.05: Failed to interpret TT instructions for glyph index 36 of font Algerian. Continue ignoring instructions of the font. End of page 1, press <enter> to continue. Without the command line switches the file displays as a page with two uppercase letters at the top on two separate lines, an A in what may be this Algerian font, and a T. gxps appears to work like gs - if no switches are given then the device defaults to X.
Tried the first PoC again, downloading it again and running: $ gxps -sDEVICE=pdfwrite -sOutputFile=/dev/null -dNOPAUSE Ins_MIRP Segmentation fault (core dumped) Unzipped it in a directory called poc. $ gxps -sDEVICE=pdfwrite -sOutputFile=/dev/null -dNOPAUSE poc Unable to open poc for reading. Referring back to earlier comments, gxps is not going to be very useful here because it has its own version of Ghostscript so would be impervious to the updates. gs on the other hand is in tune with the updates so can be used where indicated.
@Lewis It makes more sense after close examination. The type of the poc file is Microsoft OOXML (Object Oriented XML) which is a container format for the various resources needed to reproduce the "image" output. You can see XML code which itself contains font descriptions, graphics code similar to postscript and "schemas". Not something which your average image viewer would know about. I shall try to find documentation on the subject just in case anybody needs to follow this up in future.
First mistake. It may well be object orientated but OO stands for "Office Open". http://officeopenxml.com/ https://msdn.microsoft.com/en-us/library/aa338205(v=office.12).aspx Check "Structure of the Office XML formats"
Trying M5/64 (before) BEFORE the updates: ghostscript-9.20-1.mga5 ghostscript-common-9.20-1.mga5 ghostscript-module-X-9.20-1.mga5 lib64gs9-9.20-1.mga5 lib64ijs1-0.35-115.mga5 Following Len's experiences, I renamed all PoC files *.extn to just * and used this basename as the test commands file parameter. CVE-2017-9611 (Ins_MIRP) $ gxps -sDEVICE=pdfwrite -sOutputFile=/dev/null -dNOPAUSE Ins_MIRP Segmentation fault CVE-2017-9612 (Ins_IP) $ gxps -sDEVICE=pdfwrite -sOutputFile=/dev/null -dNOPAUSE Ins_IP Segmentation fault CVE-2017-9726 (Ins_MDRP) $ gxps -sDEVICE=pdfwrite -sOutputFile=/dev/null -dNOPAUSE Ins_MDRP GPL Ghostscript 9.05: Failed to interpret TT instructions for glyph index 36 of font Algerian. Continue ignoring instructions of the font. Segmentation fault CVE-2017-9727 (gx_ttfReader__Read) $ gxps -sDEVICE=pdfwrite -sOutputFile=/dev/null -dNOPAUSE gx_ttfReader__Read GPL Ghostscript 9.05: Failed to interpret TT instructions for glyph index 36 of font Unknown. Continue ignoring instructions of the font. Segmentation fault CVE-2017-9739 (Ins_JMPR) $ gxps -sDEVICE=pdfwrite -sOutputFile=/dev/null -dNOPAUSE Ins_JMPR GPL Ghostscript 9.05: Failed to interpret TT instructions for glyph index 55 of font Algerian. Continue ignoring instructions of the font. CVE-2017-9835 (gs_alloc_ref_array) $ gs -dNOPAUSE -sDEVICE=bit -sOUTPUTFILE=/dev/null -dSAFER gs_alloc_ref_array -c quit GPL Ghostscript 9.20 (2016-09-26) Copyright (C) 2016 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Error: /VMerror in (binary token, type=128) VM status: 1 1764808 3055176 Current allocation mode is local GPL Ghostscript 9.20: Unrecoverable error, exit code 1 CVE-2017-11714 (gs_oobr_igc_reloc_struct_ptr) $ gs -dNOPAUSE -sDEVICE=bit -sOUTPUTFILE=/dev/null -dSAFER gs_oobr_igc_reloc_struct_ptr -c quit GPL Ghostscript 9.20 (2016-09-26) Copyright (C) 2016 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Segmentation fault To repeat after the update.
Testing M5/64 (AFTER update) - ghostscript-9.20-1.1.mga5.x86_64 - ghostscript-common-9.20-1.1.mga5.x86_64 - ghostscript-module-X-9.20-1.1.mga5.x86_64 - lib64gs9-9.20-1.1.mga5.x86_64 - lib64ijs1-0.35-115.1.mga5.x86_64 As in comment 10, the output of all but one of the test commands was identical to beforehand; the only difference (also as previously noted) was: $ gs -dNOPAUSE -sDEVICE=bit -sOUTPUTFILE=/dev/null -dSAFER gs_oobr_igc_reloc_struct_ptr -c quit which did not segfault. HOWEVER I found that I had by mistake re-run this command before the update, and the second time it had not segfaulted! So confirmed that all these PoCs seem to illustrate nothing; and I think the discussion in comments 10-14 was a diversion. Will persue with simple 'gs' usage... Added directly from updates testing: ghostscript-dvipdf-9.20-1.1.mga5.x86_64.rpm Tried with 'gs' a variety of file types: .pdf without problems; .ps produced by Opera 12 and Firefox 'print' were both defective on display, but these browsers' PS output is suspect (Opera was always useless). $ gs ... GPL Ghostscript 9.20 (2016-09-26) note the unchanged version number. 'dvipdf' produced a good PDF page from the DVI original; in fact it lacked a small graphic symbol - which Okular displayed directly from the DVI file, but I am not complaining about that. There really is nothing conclusive to report other than that 'gs' and 'dvipdf' seem to work for display of valid file types. I think ghostscript is (or was) mainly used in the application PS output -> printer chain, which Len has tried.
Whiteboard: MGA5TOO MGA6-64-OK => MGA5TOO MGA6-64-OK MGA5-64-OK
Advisory from comments 2 & 0.
Keywords: (none) => advisory
Testing on mga5 for i586 in vbox Installed libreoffice and checked to see that it was working OK with a networked printer. OK. Installed the updates and used gs to view various postscript and pdf files. Installed gv to view the files as well. $ urpmq -i gv supplies this information: Summary : An enhanced front-end for the ghostscript PostScript(TM) interpreter That can be used in the same way as gs. It has a facility to print documents which is a bit clumsy to use and does not seem to work. It asks the user to supply the print command so it is in fact easier to go straight to the commandline. lpr works fine from a terminal. $ lpr -Pokda abc-1.pdf $ lpr -Pokda ticket.ps The postscript file contained graphics, colours and mixed fonts and rendered perfectly. libreoffice --writer printed all formats without a problem. OK for 32-bit.
Whiteboard: MGA5TOO MGA6-64-OK MGA5-64-OK => MGA5TOO MGA6-64-OK MGA5-64-OK MGA5-32-OK
Testing in i586 vbox for mga6 Installed many base packages before the update. Put gs through its paces before the update. Started cups Set up a network printer queue under hplip and printed a test page. dvipdf did not work very well. An experiment on my production machine (mga6:x86_64) worked fine. Copied two dvi files to this vbox and tried dvipdf on one of them here. The conversion appeared to succeed after a very long time (~10 minutes), with a number of comments which matched those on the production machine, but the pdf file generated a huge number of comments in xpdf. Otherwise it looked OK. Onto the updates. I need to reboot for glibc.
Installed the updates. Printed odt document from LibreOffice writer and a postscript file from LO draw. Used gs to view postscript and pdf files. $ gs GPL Ghostscript 9.20 (2016-09-26) Copyright (C) 2016 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. GS>(ticket.ps) run Querying operating system for font files... Can't find (or can't open) font file /usr/share/ghostscript/9.20/Resource/Font/AndaleMono. Can't find (or can't open) font file AndaleMono. Didn't find this font on the system! Substituting font Courier for AndaleMono. Loading NimbusMonoPS-Regular font from /usr/share/ghostscript/9.20/Resource/Font/NimbusMonoPS-Regular... 3995120 2639554 6790660 5388913 3 done. >>showpage, press <return> to continue<< GS>(refcard.pdf) run Processing pages 1 through 6. Page 1 >>showpage, press <return> to continue<< Page 2 >>showpage, press <return> to continue<< Page 3 >>showpage, press <return> to continue<< Page 4 >>showpage, press <return> to continue<< Page 5 >>showpage, press <return> to continue<< Page 6 >>showpage, press <return> to continue<< GS>quit Both documents were displayed accurately, including colours and graphics. DVI conversion is a heavyweight job for virtualbox with its meagre resources but it completed inside a minute. $ dvipdf refcard.dvi emacs.pdf dvips: Font cmbx10 at 13824 not found; scaling 600 instead. dvips: Such scaling will generate extremely poor output. Page 1 may be too complex to print Page 2 may be too complex to print Page 5 may be too complex to print Page 6 may be too complex to print Warning: no %%Page comments generated. The resulting PDF file looked perfectly OK in xpdf, all six pages, but with a host of warnings, all the same. Syntax Warning: Bad bounding box in Type 3 glyph This update looks good for 32-bits.
Whiteboard: MGA5TOO MGA6-64-OK MGA5-64-OK MGA5-32-OK => MGA5TOO MGA6-64-OK MGA5-64-OK MGA5-32-OK MGA6-32-OKKeywords: (none) => validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2017-0355.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED