FS#62785 - [imagemagick] Remove Security Workaround

Attached to Project: Arch Linux
Opened by jayki (jayki) - Friday, 31 May 2019, 14:19 GMT
Last edited by Antonio Rojas (arojas) - Sunday, 21 July 2019, 13:21 GMT
Task Type Feature Request
Category Packages: Testing
Status Closed
Assigned To Antonio Rojas (arojas)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:
Remove workaround introduced here: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/imagemagick&id=4f25329acbad8372b4bbb45a7cdcd99752541d7c

Ghostscript is updated since ages, there is no security issue anymore but the workaround/mitigation is still deployed even on new systems..

Additional info:
* package version(s) 7.0.8.47-2
This task depends upon

Closed by  Antonio Rojas (arojas)
Sunday, 21 July 2019, 13:21 GMT
Reason for closing:  Fixed
Additional comments about closing:  imagemagick 7.0.8.56-1
Comment by Jake Kreiger (Magali75) - Friday, 31 May 2019, 17:59 GMT
The workaround was supposed to be permanent as a security enhancement. This is recommendation from people who discovered dozens of ghostscript vulnerabilities. Modification of the 'workaround' was proposed here: https://bugs.archlinux.org/task/62171
Comment by Antonio Rojas (arojas) - Friday, 31 May 2019, 18:02 GMT
If this is meant to be permanent, it should go upstream. I'm against permanently shipping a non-upstreamed patch, unless there is an actual, unfixed security issue.
Comment by Jake Kreiger (Magali75) - Friday, 31 May 2019, 19:50 GMT
We're talking about config, not patching the code. Upstream delegates configuration for downstream: https://imagemagick.org/script/security-policy.php

"ImageMagick best practices strongly encourages you to configure a security policy.xml that suits your local environment. The policy is open by default. This affords maximum utility for ImageMagick installations that run in a sandboxed environment, perhaps in a Docker instance, or behind a firewall where security risks are greatly diminished as opposed to a public website."

Feel free to remove modifications as you wish.


Comment by Juan Simón (j1simon) - Tuesday, 09 July 2019, 09:45 GMT
I don't know if this is related but I want to convert a PDF file (created for me with Libreoffice) to PNG but:

$ convert artículo\ prensa\ problema\ casero-EN.pdf artículo\ prensa\ problema\ casero-EN.png
convert: attempt to perform an operation not allowed by the security policy `PDF' @ error/constitute.c/IsCoderAuthorized/408.
convert: no images defined `artículo prensa problema casero-EN.png' @ error/convert.c/ConvertImageCommand/3273.

Why won't you let me convert my PDF to PNG? I understand that this would be denied if the PDF to be converted had some security limitation but doing so as a rule seems absurd to me.
Comment by Jan Alexander Steffens (heftig) - Tuesday, 09 July 2019, 11:04 GMT
I think we should patch the installed policy file in package(), then. It would make it more obvious this is a change to the default configuration and also obsolete the hack in check().
Comment by Ashwin Vishnu (jadelord) - Wednesday, 17 July 2019, 16:45 GMT
I second @j1simon. Convert is a common CLI tool and this affects user directly. So, IMHO, it outweighs the risk of avoiding an unknown exploit. Here it is clearly mentioned it has been resolved in Ghostscript version 9.24

https://www.kb.cert.org/vuls/id/332928/
Comment by Michel Koss (MichelKoss1) - Thursday, 18 July 2019, 10:36 GMT
@jadelord

There were multiple security issues past 9.24 release, please improve your research: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ghostscript
Comment by Juan Simón (j1simon) - Friday, 19 July 2019, 15:33 GMT
I think this is a better solution: https://bugs.archlinux.org/task/62171

Loading...