RedHat has issued an advisory on May 7: https://access.redhat.com/errata/RHSA-2019:1017 The issue is fixed upstream in 9.28. Mageia 6 is also affected.
Status comment: (none) => Fixed upstream in 9.28Whiteboard: (none) => MGA6TOO
Assigning globally as ghostscript has no registered mainatainer.
CC: (none) => lewyssmithAssignee: bugsquad => pkg-bugs
After checking, in fact, version 9.27 already contains the fixes for CVE-2019-3839 so only Mageia 6 is affected. Suggested advisory: ======================== The updated packages fix a security vulnerability: It was found that in ghostscript some privileged operators remained accessible from various places after the CVE-2019-6116 fix. A specially crafted PostScript file could use this flaw in order to, for example, have access to the file system outside of the constrains imposed by -dSAFER. Ghostscript versions before 9.28 are vulnerable. (CVE-2019-3839) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-3839 https://access.redhat.com/errata/RHSA-2019:1017 ======================== Updated packages in core/updates_testing: ======================== ghostscript-9.26-1.4.mga6 ghostscript-dvipdf-9.26-1.4.mga6 ghostscript-common-9.26-1.4.mga6 ghostscript-X-9.26-1.4.mga6 ghostscript-module-X-9.26-1.4.mga6 lib(64)gs9-9.26-1.4.mga6 lib(64)gs-devel-9.26-1.4.mga6 lib(64)ijs1-0.35-143.4.mga6 lib(64)ijs-devel-0.35-143.4.mga6 ghostscript-doc-9.26-1.4.mga6 from SRPMS: ghostscript-9.26-1.4.mga6.src.rpm
Whiteboard: MGA6TOO => (none)Source RPM: ghostscript-9.27-1.mga7.src.rpm => ghostscript-9.26-1.3.mga6.src.rpmAssignee: pkg-bugs => qa-bugsStatus: NEW => ASSIGNEDCC: (none) => nicolas.salgueroVersion: Cauldron => 6
CC: lewyssmith => (none)
mga6, x86_64 Updated the ten packages. Attempted to find reproducers for CVE-2019-3839 but the backtrail is very confusing with references to bugs already fixed and exploits which start with ImageMagick. https://seclists.org/oss-sec/2018/q3/142 $ gs -q -sDEVICE=ppmraw -dSAFER -sOutputFile=/dev/null GS>legal GS>{ null restore } stopped { pop } if GS>legal GS>mark /OutputFile (%pipe%id) currentdevice putdeviceprops Error: /invalidaccess in --.putdeviceprops-- [...] The test above looks the same before and after the update and shows that the exploit has been nipped in the bud. $ gs -q -sDEVICE=ppmraw -dSAFER GS>/home/lcl/tmp/abc-0.ps 16#414141414141 setpattern Error: /typecheck in --setpattern-- [...] That is probably a good result (lost the "before" check, which did not segfault). $ gs -q -sDEVICE=ppmraw -dSAFER GS>/home/lcl/tmp/abc-0.ps 16#4141414141414141 .setdistillerparams Error: /typecheck in --.setdistillerparams-- Ran this (above) only after the update - not too sure about the input file. Again, no segfault. Tried the steal file trick without being sure how to execute it or its relation to the current bug. fileread.ps on localhost $ gs -q -sDEVICE=ppmraw -dSAFER fileread.ps STOLEN: /HalftoneDefault/HalftoneDefault-device--dict--dict--dict--dict- which looks innocuous. If it had worked the output would have been more like: STOLEN: root:x:0:0:root: STOLEN: daemon:x:1:1:daemon:/bash/bin/root:(/etc/passwd) STOLEN: bin:x:2:2:bin:/nologin/sbin/usr/sbin:/usr(/etc/passwd) [...] Ran several of the tests which have been used here before to check functionality, like reading a Postscript file with gs and displaying it and then printing it. Also: $ dvipdf refcard.dvi refcard.pdf The generated PDF file displayed perfectly in a PDF viewer. $ gs -dSAFER -dNODISPLAY GPL Ghostscript 9.26 (2018-11-20) Copyright (C) 2018 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. GS>1183615869 internaldict /superexec known { (VULNERABLE\n) } { (SAFE\n) } GS<3>ifelse print SAFESAFE GS>quit No regressions.
Whiteboard: (none) => MGA6-64-OKCC: (none) => tarazed25
Created attachment 11019 [details] Short exploit script for file stealing To be run interactively with gs cli.
Printing broke after i installed this set yesterday: lib64ijs1-0.35-143.4.mga6.x86_64 tis 21 maj 2019 23:00:39 ghostscript-module-X-9.26-1.4.mga6.x86_64 tis 21 maj 2019 23:00:39 lib64gs-devel-9.26-1.4.mga6.x86_64 tis 21 maj 2019 23:00:38 lib64gs9-9.26-1.4.mga6.x86_64 tis 21 maj 2019 23:00:38 ghostscript-9.26-1.4.mga6.x86_64 tis 21 maj 2019 23:00:38 ghostscript-common-9.26-1.4.mga6.x86_64 tis 21 maj 2019 23:00:36 In Cups interface there is the message "filter failed" Reboot did not help. After i now issued: # urpmi --downgrade --media "Core Updates" lib64ijs1 ghostscript-module-X lib64gs-devel lib64gs9 ghostscript ghostscript-common Then printing started to work again, without needing to reboot. Also the queued failed prints work when i there tell it to resend the job. Printer is ethernet attached Canon i-Sensys LBP7750Cdn. I installed it over a year ago according to my posting https://forums.mageia.org/en/viewtopic.php?f=24&t=4203 using queue type PXL (PCL6).
CC: (none) => friWhiteboard: MGA6-64-OK => (none)
If i update only lib64ijs1 to -0.35-143.4.mga6.x86_64 it still works, also after reboots, so that is not the guilty one. After i update the other five packages ( = from ghostscript-9.26-1.4.mga6.src.rpm ) printing stops working on this system. Symptom is that the printer dialog progress as usual even the bar showing progress of pages, but at http://localhost:631/jobs/ the state of the job is: stopped "Filter failed"
In reply to comment 5; Hmm. Had not noticed that. When this is run:- $ lpr -Pokda tmp/abc-0.ps The page is printed and "show active jobs" has entries for previous jobs with the messages: Stopped "Filter failed" but nothing for the current job. So something odd is going on here. The other oddity is that the successful job is listed as having 3 pages when it actually had only 1. I am beginning to think that I am misinterpreting the job numbers, which may refer to other past jobs. 'Reprint job' produces a single blank page. Tried libreoffice writer as well with a single page ODT file, specifying printer okda and that worked. Its job number was okda-130 which is listed as "completed" (no filter failed). Repeating the cli command resulted in job okda-131 being posted and completed. No entry in active jobs. In my case the "filter failed" jobs seem to be old, long forgotten ones, so not relevant to the update. The report above is confusing - it confuses me - but the upshot is that I cannot reproduce the problem you are seeing but it may have occurred with previous versions of ghostscript.
Re comment 7: all the listed packages have been installed.
I have had "filter failed" errors before when installation of printers have gone wrong. With updated gs, wehn i print several pages i see the print dialog progress bar move and all pages get "printed" and the progress window closes. I guess that the intermediate postscript (?) file have then been generated OK. But then cups fail to print that intermediate file. Maybe there is some incompatibility between this specific printer drivers filter and the new version of ghostscript. I am not sure what "filter" mean in this case. I guess that is something coming from the Canon package. Maybe i should try updating that by reinstalling newer version. On the other hand we should not ship a ghostscript that riskt stopping printing for users. Hard to know if this should affect only a very few or many. Is there a way to get more debug info than just "Filter failed" ?
There are mentions of incompatible changes for 9.27 https://www.ghostscript.com/doc/current/News.htm I could not now quicky locate additional changes for 9.28 I guess i should take this upstream but have a work deadline to take care of...
In reply to comment 9. In my case all printers are Hewlett-Packard and have been installed under HPLIP so whatever 'filter' means it seems to be something general. Searching the web turns up several links about the 'filter failed' problem. In the case of a Mac with HP printer HP advised 'resetting' the printer. In the case of CUPS I cannot see anything about reset in either Maintenance or Administration. Checking other replies I see that some Ubuntu users have seen the same fault, which happened suddenly in all cases. Solutions varied from reinstalling the printer or restarting the CUPS server to emptying /var/spool/cups and updating network printers addresses. So, a messy problem. No indication what 'filter' means but my understanding is covered by the quote below. Occasionally, in the past, I have had to remove and reinstall the printer to overcome problems. That seems a clumsy solution though and you can never be sure that it is going to work. Quote from one source: Description. The CUPS filter interface provides a standard method for adding support for new document types or printers to CUPS. Each filter is capable of converting from one or more input formats to another format that can either be printed directly or piped into another filter to get it to a printable format.
Ah, i guess then the "filter" is a translator from ps to in my case the PCL dialect for my printer. And ps dialect have changed now so it fails. Maybe the update should come with some information that the printer driver need be updated because some non-standard and undocumented operators have been removed, and reference the link i gave. I will try in the weekend or maybe earlier maybe to update the Canon package.
@Morgan, comment 12. Have you been able to test this again?
Tonight or tomorrow.
Darn. didnt find time for this and now i have to leave for a week. I think this should not stop it from being validated. Upstream do say incompatible changes are introduced. IMO there should be package information saying that in case the printer does not work anymore, try to get a newer printer driver/filter and (re)install that.
OK, thanks Morgan. Sending this on.
Whiteboard: (none) => MGA6-64-OKKeywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Keywords: (none) => advisoryCC: (none) => tmb
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2019-0188.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
I've opened bug#25020 on the "filter failed" error in comment#7.
CC: (none) => dan