A CVE has been assigned for a security issue fixed upstream in graphicsmagick: http://openwall.com/lists/oss-security/2016/02/06/3 It is fixed in the version in Cauldron. Upstream change to fix it checked into Mageia 5 SVN. I'll push the build later. Reproducible: Steps to Reproduce:
Other vulnerabilities in the SVG decoder were announced today: http://seclists.org/oss-sec/2016/q1/297 There are no fixes yet. The CVE-2015-8808 issue sounds like a minor one, so I think we can wait for more fixes before pushing an update.
(In reply to David Walser from comment #1) > Other vulnerabilities in the SVG decoder were announced today: > http://seclists.org/oss-sec/2016/q1/297 > > There are no fixes yet. CVE-2016-2317 and CVE-2016-2318 for these newer issues: http://openwall.com/lists/oss-security/2016/02/11/6
Summary: graphicsmagick new security issue CVE-2015-8808 => graphicsmagick new security issues CVE-2015-8808, CVE-2016-2317, and CVE-2016-2318
Assigning to packagers collectively since graphicsmagick has no registered maintainer. To packagers: it would be nice to have a maintainer for this package that is a dependency for many others, so that David Walser knows who to assign security bugs to. David, can you assign new security bugs to pkg-bugs directly when there is no maintainer to assign to?
Assignee: bugsquad => pkg-bugs
URL: (none) => http://lwn.net/Vulnerabilities/677107/
CVE request for more graphicsmagick issues: http://seclists.org/oss-sec/2016/q2/180 These are apparently fixed upstream in their version control repository: http://openwall.com/lists/oss-security/2016/05/01/6
here are the two patches : CVE-2016-2318 https://sourceforge.net/p/graphicsmagick/code/ci/e797bb0aec31941c454e6f764f9589d3b1843547/ CVE-2016-2317 https://sourceforge.net/p/graphicsmagick/code/ci/98394eb235a6dc5d6b4d445023ae1c70189a7667/ Perhaps we should also include https://sourceforge.net/p/graphicsmagick/code/ci/9ba30629488e95a5b796db9af13aab979e09c139/ But CVE-2016-2318 is a huge patch, and I failed to apply it
CC: (none) => makowski.mageia
Created attachment 7739 [details] Patch for CVE-2016-2317 that applies to Mga5 and Cauldron
CC: (none) => nicolas.salguero
Created attachment 7740 [details] Patch for CVE-2016-2318 that applies to Mga5 only
Created attachment 7741 [details] Patch for CVE-2016-2318 that applies to Cauldron only Hi, Here are three patches for CVE-2016-2317 and CVE-2016-2318. Best regards, Nico.
Thanks Nicolas, will try these.
Updated packages uploaded for Mageia 5 and Cauldron Advisory: ======================== Updated graphicsmagick package fixes security vulnerability: A read out-of-bound in the parsing of gif files using GraphicsMagick (CVE-2016-8808). Infinite loop caused by converting a circularly defined svg file (CVE-2016-2317). Arithmetic exception converting a svg file caused by a X%0 operation in magick/render.c (CVE-2016-2318) References: - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2317 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2318 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8808 - http://openwall.com/lists/oss-security/2016/05/01/6 - http://openwall.com/lists/oss-security/2016/02/06/3 - http://lwn.net/Vulnerabilities/677107/ Updated packages in core/updates_testing: ======================== graphicsmagick-1.3.20-4.1.mga5 graphicsmagick-doc-1.3.20-4.1.mga5.noarch lib64graphicsmagick3-1.3.20-4.1.mga5 lib64graphicsmagick-devel-1.3.20-4.1.mga5 lib64graphicsmagickwand2-1.3.20-4.1.mga5 libgraphicsmagick3-1.3.20-4.1.mga5 libgraphicsmagick-devel-1.3.20-4.1.mga5 libgraphicsmagickwand2-1.3.20-4.1.mga5 perl-Graphics-Magick-1.3.20-4.1.mga5 from graphicsmagick-1.3.20-4.1.mga5.src.rpm
Assignee: pkg-bugs => qa-bugs
There have been many security related fixes upstream, and more may be coming according to this message from an upstream developer on April 27: http://openwall.com/lists/oss-security/2016/04/27/11 I'm not sure when he'll be done with those issues, but hopefully they'll release a new version at that time. If we're going to update this for Mageia 5, it would probably be best to update to the latest code upstream, rather than trying to cherry-pick patches.
Indeed, see their response to the recent ImageMagick situation: https://sourceforge.net/p/graphicsmagick/mailman/message/35072963/
Whiteboard: (none) => feedback
CC: (none) => qa-bugsAssignee: qa-bugs => makowski.mageia
Assigning Philippe til it's ready
Just to make more clear why I'm waiting for upstream to make a new release: http://openwall.com/lists/oss-security/2016/05/20/4 So hopefully they will make one soon.
LWN reference for CVE-2016-231[78]: http://lwn.net/Vulnerabilities/688448/
A CVE has been assigned for another issue, CVE-2016-5118: http://openwall.com/lists/oss-security/2016/05/30/1 The initial post in the thread had a patch to disable the vulnerable feature.
Summary: graphicsmagick new security issues CVE-2015-8808, CVE-2016-2317, and CVE-2016-2318 => graphicsmagick new security issues CVE-2015-8808, CVE-2016-2317, CVE-2016-2318, CVE-2016-5118
(In reply to David Walser from comment #16) > A CVE has been assigned for another issue, CVE-2016-5118: > http://openwall.com/lists/oss-security/2016/05/30/1 > > The initial post in the thread had a patch to disable the vulnerable feature. So if I add this patch to graphicsmagick-1.3.20-4.1.mga5.src.rpm, we can release a package that fix CVE-2015-8808, CVE-2016-2317, CVE-2016-2318, CVE-2016-5118
If we want to release something, you should pull a snapshot of upstream git, as it contains a lot more security fixes that don't have CVEs.
Hi, Version 1.3.24 is published: https://sourceforge.net/projects/graphicsmagick/files/graphicsmagick/1.3.24/GraphicsMagick-1.3.24.tar.xz/download. Best regards, Nico.
Updated packages uploaded for Mageia 5 and Cauldron (freeze push asked) Advisory: ======================== Updated graphicsmagick package fixes security vulnerability: A read out-of-bound in the parsing of gif files using GraphicsMagick (CVE-2015-8808). Infinite loop caused by converting a circularly defined svg file (CVE-2016-2317). Arithmetic exception converting a svg file caused by a X%0 operation in magick/render.c (CVE-2016-2318) A shell exploit (CVE-2016-5118) was discovered associated with a filename syntax where file names starting with '|' are intepreted as shell commands executed via popen(). Insufficient sanitization in the SVG and MVG renderers allows such filenames to be passed through from potentially untrusted files. There might be other ways for untrusted inputs to produce such filenames. Due to this issue, support for the feature is removed entirely. References: - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2317 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2318 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8808 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5118 - http://openwall.com/lists/oss-security/2016/05/01/6 - http://openwall.com/lists/oss-security/2016/02/06/3 - http://lwn.net/Vulnerabilities/677107/ - http://openwall.com/lists/oss-security/2016/05/30/1 - http://www.graphicsmagick.org/NEWS.html Updated packages in core/updates_testing: ======================== graphicsmagick-1.3.24-1.mga5 graphicsmagick-doc-1.3.24-1.mga5.noarch lib64graphicsmagick3-1.3.24-1.mga5 lib64graphicsmagick-devel-1.3.24-1.mga5 lib64graphicsmagickwand2-1.3.24-1.mga5 libgraphicsmagick3-1.3.24-1.mga5 libgraphicsmagick-devel-1.3.24-1.mga5 libgraphicsmagickwand2-1.3.24-1.mga5 perl-Graphics-Magick-1.3.24-1.mga5 from graphicsmagick-1.3.24-1.mga5.src.rpm
Assignee: makowski.mageia => qa-bugsWhiteboard: feedback => (none)
Thanks! Summary of security improvements in 1.3.24 from the upstream author: http://openwall.com/lists/oss-security/2016/05/27/4
In VirtualBox, M5, KDE, 32-bit Test procedure: https://wiki.mageia.org/en/QA_procedure:GraphicsMagick Images used: image1.jpg image2.jpg image3.jpg image4.jpg number1.png number2.png number3.png perl script gmtest.pl: #!/usr/local/bin/perl # taken from http://www.graphicsmagick.org/perl.html#example-script use Graphics::Magick; my($image, $status); $image = Graphics::Magick->new; $status = $image->Read('number1.png', 'number2.png', 'number3.png'); warn "$status" if "$status"; $status = $image->Write('numbers.gif'); warn "$status" if "$status"; Package(s) under test: graphicsmagick libgraphicsmagick3 perl-Graphics-Magick default install of packages: [root@localhost wilcal]# urpmi graphicsmagick Package graphicsmagick-1.3.20-4.mga5.i586 is already installed [root@localhost wilcal]# urpmi libgraphicsmagick3 Package libgraphicsmagick3-1.3.20-4.mga5.i586 is already installed [root@localhost wilcal]# urpmi perl-Graphics-Magick Package perl-Graphics-Magick-1.3.20-4.mga5.i586 is already installed gm convert image1.jpg image1.png gm convert image2.jpg image2.tiff gm convert image2.jpg image2.png gm convert image3.jpg image3.pdf gm convert image3.jpg image3.png gm convert -rotate +90 image4.jpg image4_rotated.jpg gm display -flip image4.jpg gm identify image4.jpg All work execute gmtest.pl produces an animated gif Package(s) under test: graphicsmagick libgraphicsmagick3 perl-Graphics-Magick install graphicsmagick libgraphicsmagick3 & perl-Graphics-Magick from updates_testing [root@localhost wilcal]# urpmi graphicsmagick Package graphicsmagick-1.3.24-1.mga5.i586 is already installed [root@localhost wilcal]# urpmi libgraphicsmagick3 Package libgraphicsmagick3-1.3.24-1.mga5.i586 is already installed [root@localhost wilcal]# urpmi perl-Graphics-Magick Package perl-Graphics-Magick-1.3.24-1.mga5.i586 is already installed gm convert image1.jpg image1.png gm convert image2.jpg image2.tiff gm convert image2.jpg image2.png gm convert image3.jpg image3.pdf gm convert image3.jpg image3.png gm convert -rotate +90 image4.jpg image4_rotated.jpg gm display -flip image4.jpg gm identify image4.jpg All work execute gmtest.pl produces an animated gif
CC: (none) => wilcal.int
Whiteboard: (none) => MGA5-32-OK
In VirtualBox, M5, KDE, 64-bit Test procedure: https://wiki.mageia.org/en/QA_procedure:GraphicsMagick Images used: image1.jpg image2.jpg image3.jpg image4.jpg number1.png number2.png number3.png perl script gmtest.pl: #!/usr/local/bin/perl # taken from http://www.graphicsmagick.org/perl.html#example-script use Graphics::Magick; my($image, $status); $image = Graphics::Magick->new; $status = $image->Read('number1.png', 'number2.png', 'number3.png'); warn "$status" if "$status"; $status = $image->Write('numbers.gif'); warn "$status" if "$status"; Package(s) under test: graphicsmagick lib64graphicsmagick3 perl-Graphics-Magick default install of packages: [root@localhost wilcal]# urpmi graphicsmagick Package graphicsmagick-1.3.20-4.mga5.x86_64 is already installed [root@localhost wilcal]# urpmi lib64graphicsmagick3 Package lib64graphicsmagick3-1.3.20-4.mga5.x86_64 is already installed [root@localhost wilcal]# urpmi perl-Graphics-Magick Package perl-Graphics-Magick-1.3.20-4.mga5.x86_64 is already installed gm convert image1.jpg image1.png gm convert image2.jpg image2.tiff gm convert image2.jpg image2.png gm convert image3.jpg image3.pdf gm convert image3.jpg image3.png gm convert -rotate +90 image4.jpg image4_rotated.jpg gm display -flip image4.jpg gm identify image4.jpg All work execute gmtest.pl produces an animated gif install graphicsmagick lib64graphicsmagick3 & perl-Graphics-Magick from updates_testing [root@localhost wilcal]# urpmi graphicsmagick Package graphicsmagick-1.3.24-1.mga5.x86_64 is already installed [root@localhost wilcal]# urpmi lib64graphicsmagick3 Package lib64graphicsmagick3-1.3.24-1.mga5.x86_64 is already installed [root@localhost wilcal]# urpmi perl-Graphics-Magick Package perl-Graphics-Magick-1.3.24-1.mga5.x86_64 is already installed gm convert image1.jpg image1.png gm convert image2.jpg image2.tiff gm convert image2.jpg image2.png gm convert image3.jpg image3.pdf gm convert image3.jpg image3.png gm convert -rotate +90 image4.jpg image4_rotated.jpg gm display -flip image4.jpg gm identify image4.jpg All work execute gmtest.pl produces an animated gif
Whiteboard: MGA5-32-OK => MGA5-32-OK MGA5-64-OK
This looks good. What you say David?
(In reply to William Kenney from comment #24) > This looks good. What you say David? For the most part, it should be good. There's a PoC for CVE-2016-5118 which should be easy to test. There may be for other CVEs here, I can't remember. Worth a look.
(In reply to David Walser from comment #25) > For the most part, it should be good. There's a PoC for CVE-2016-5118 which > should be easy to test. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5118 Boy I didn't see anything in there to test. You'll have to tell me where to look.
@wilcal Re PoC, poked around a bit out of curiosity. A Google search on the CVE and poc returned one or two possible links and one of them led to another http://www.openwall.com/lists/oss-security/2016/05/29/7 containing a commandline script which demonstrates the pipe functionality. It looks like the patch disables this but I am not sure about it or exactly how to use it as a PoC.
CC: (none) => tarazed25
I could not find anything POC-wise from the CVE URLs. http://openwall.com/lists/oss-security/2016/05/01/6 says "Reproducers for both issues are attached" (SVG issues), but I could not find those. http://openwall.com/lists/oss-security/2016/02/06/3 includes "$ ./gm identify overflow.gif" (a GIF issue), but no sign of the test image file. I note these in case anyone can unearth the POCs indicated. Len's link http://www.openwall.com/lists/oss-security/2016/05/29/7 looks promising. $ rm hello.txt rm: cannot remove âhello.txtâ: No such file or directory $ convert '|echo Hello > hello.txt;' null: convert: no decode delegate for this image format `TXT;' @ error/constitute.c/ReadImage/504. convert: no images defined `null:' @ error/convert.c/ConvertImageCommand/3257. $ ls hello.txt hello.txt is clearly wrong; except 'convert' is here ImageMagick. If someone could say how to invoke the XML script, that might help. Or explain "in MVG" for the last test example.
CC: (none) => lewyssmith
openwall.com's archive strips attachments, so you have to use the seclists.org archive for those.
CVE-2015-8808: http://seclists.org/oss-sec/2016/q1/289 (I'm not seeing the attachment...) CVE-2016-2317 and CVE-2016-2318: http://seclists.org/oss-sec/2016/q1/297 Another DoS issue: http://seclists.org/oss-sec/2016/q2/180 CVE-2016-5118: http://seclists.org/oss-sec/2016/q2/432
It looks like from wilcal's tests, you use the convert command to test imagemagick and "gm convert" to test graphicsmagick.
Lets move this on
(In reply to William Kenney from comment #32) > Lets move this on How about we test some of the bugs we're fixing first?
Indeed, the CVE-2016-5118 patch appears to have not been included in the 1.3.24 release.
Whiteboard: MGA5-32-OK MGA5-64-OK => feedback
(In reply to David Walser from comment #34) > Indeed, the CVE-2016-5118 patch appears to have not been included in the > 1.3.24 release. Pretty easy to test for me now.
(In reply to William Kenney from comment #35) > (In reply to David Walser from comment #34) > > > Indeed, the CVE-2016-5118 patch appears to have not been included in the > > 1.3.24 release. > > Pretty easy to test for me now. The PoC's should be easy to test too.
(In reply to David Walser from comment #34) > Indeed, the CVE-2016-5118 patch appears to have not been included in the > 1.3.24 release. OK upstream actually committed a different fix for that: https://sourceforge.net/p/graphicsmagick/code/ci/ae3928faa858f28aed36a99a32f4d1c4a18e843b/tree/magick/blob.c?diff=c37414f6aee5175e3fa7022ba020119e7c48130f which is in 1.3.24. They have since added another commit fixing further SVG issues: https://sourceforge.net/p/graphicsmagick/code/ci/6071b5820215fb00f6395bf13f4b3109ea14b1de/
(In reply to David Walser from comment #4) > CVE request for more graphicsmagick issues: > http://seclists.org/oss-sec/2016/q2/180 > > These are apparently fixed upstream in their version control repository: > http://openwall.com/lists/oss-security/2016/05/01/6 We now have CVEs for this, these are fixed in our update candidate: http://www.openwall.com/lists/oss-security/2016/06/02/14 CVE-2016-5240 and CVE-2016-5241.
Summary: graphicsmagick new security issues CVE-2015-8808, CVE-2016-2317, CVE-2016-2318, CVE-2016-5118 => graphicsmagick new security issues CVE-2015-8808, CVE-2016-2317, CVE-2016-2318, CVE-2016-5118, CVE-2016-524[01]
Thanks to Bill for his extensive tests. Trying some PoC's BEFORE the update: graphicsmagick-1.3.20-4.mga5 lib64graphicsmagick3-1.3.20-4.mga5 lib64graphicsmagickwand2-1.3.20-4.mga5 I wonder whether some of them are already fixed. To see. I will upload the test files in question, and the commands to use them. From http://seclists.org/oss-sec/2016/q2/432: $ cat hello.txt cat: hello.txt: No such file or directory $ gm convert '|echo Hello > hello.txt;' null: gm convert: Unable to open file (/tmp/gmEkDFIY) [No such file or directory]. $ cat hello.txt Hello but the XML and MVG examples still baffle me - how to? From http://seclists.org/oss-sec/2016/q1/297: $ gm convert -resize 128x128 1114777018469422437.svg bmp:/dev/null Segmentation fault $ gm convert -resize 128x128 632425326915265752.svg bmp:/dev/null Segmentation fault $ gm convert -resize 128x128 7101924735921376511.svg bmp:/dev/null gm convert: Unrecognized color (yf). $ gm convert -resize 128x128 4071333061660627683.svg bmp:/dev/null Segmentation fault $ gm convert -resize 128x128 4495884156523242589.svg bmp:/dev/null gm convert: Pixel cache allocation failed (/tmp/gmfqxa8R). $ gm convert -resize 128x128 7960082311810466150.svg bmp:/dev/null gm convert: Unrecognized color (vr). From http://seclists.org/oss-sec/2016/q2/180: $ gm convert circular.svg bmp:/dev/null [got stuck - looping] ^C^C^CKilled $ gm convert sigfpe.svg bmp:/dev/null Aborted Before trying the update with these PoC's, I am unsure whether we expect another revision or not.
Created attachment 7898 [details] First test case from http://seclists.org/oss-sec/2016/q1/297 $ gm convert -resize 128x128 1114777018469422437.svg bmp:/dev/null Error before update: segfaults
Created attachment 7899 [details] Second test file from http://seclists.org/oss-sec/2016/q1/297 $ gm convert -resize 128x128 632425326915265752.svg bmp:/dev/null Error before update: segfault
Thanks Lewis. It's worth testing the PoC's now with the update candidate as they should all be fixed. I was just hoping that Philippe would add the patch in Comment 37.
Created attachment 7900 [details] Third test case from http://seclists.org/oss-sec/2016/q1/297 $ gm convert -resize 128x128 7101924735921376511.svg bmp:/dev/null Before update: gm convert: Unrecognized color (yf). Perhaps already fixed.
Created attachment 7901 [details] Fourth test case from http://seclists.org/oss-sec/2016/q1/297 $ gm convert -resize 128x128 4071333061660627683.svg bmp:/dev/null Before update: segfaults.
Created attachment 7902 [details] Fifth test case from http://seclists.org/oss-sec/2016/q1/297 $ gm convert -resize 128x128 4495884156523242589.svg bmp:/dev/null Error ? before update: gm convert: Pixel cache allocation failed
Created attachment 7903 [details] Sixth test case from http://seclists.org/oss-sec/2016/q1/297 $ gm convert -resize 128x128 7960082311810466150.svg bmp:/dev/null Before update: gm convert: Unrecognized color (vr). Perhaps already fixed.
Created attachment 7904 [details] First test image from http://seclists.org/oss-sec/2016/q2/180 $ gm convert circular_svg bmp:/dev/null Error before update: loops.
Created attachment 7905 [details] Second test image from http://seclists.org/oss-sec/2016/q2/180 $ gm convert sigfpe.svg bmp:/dev/null Error pre-update: Aborted
Re Comment 39 Testing the PoC's AFTER update, M5 x64: $ cat hello.txt cat: hello.txt: No such file or directory $ gm convert '|echo Hello > hello.txt;' null: gm convert: Unable to open file (|echo Hello > hello.txt;) [No such file or directory]. $ cat hello.txt cat: hello.txt: No such file or directory which is now correct. $ gm convert -resize 128x128 1114777018469422437.svg bmp:/dev/nul gm convert: invalid primitive argument (-7.8248073938802944in). previously segfault, so assume this result valid. $ gm convert -resize 128x128 632425326915265752.svg bmp:/dev/null gm convert: invalid primitive argument (-9.010965059851289mm). previously segfault, so assume this result valid. $ gm convert -resize 128x128 7101924735921376511.svg bmp:/dev/null gm convert: invalid primitive argument (-67%). previously a different error, so something has changed not for the worse. $ gm convert -resize 128x128 4071333061660627683.svg bmp:/dev/null gm convert: Extra content at the end of the document . previously segfault, so assume this result valid. $ gm convert -resize 128x128 4495884156523242589.svg bmp:/dev/null gm convert: invalid primitive argument (-2.453152686783691cm). previously "Pixel cache allocation failed", so this looks better. $ gm convert -resize 128x128 7960082311810466150.svg bmp:/dev/null gm convert: Non-conforming drawing primitive definition (push) previously a different error, so something has changed not for the worse. $ gm convert circular.svg bmp:/dev/null gm convert: Negative or zero image size (circular.svg). previously looped, so this is better. $ gm convert sigfpe.svg bmp:/dev/null gm convert: invalid primitive argument (-3.3976393189840888in). previously "Aborted", so this has changed not for the worse. So with Bill's extensive tests, this update looks good for the moment. OK.
Whiteboard: feedback => feedback MGA5-64-OK
Looks good Lewis, let's loose it.
The following packages have to be removed for others to be upgraded: kde-pdf-servicemenu-0.6-2.mga5.noarch (due to missing pdf2djvu) pdf2djvu-0.7.17-4.mga5.x86_64 (due to missing libGraphicsMagick++.so.3()(64bit)) $ rpm -qa|grep graphicsmagick3 lib64graphicsmagick3-1.3.20-4.mga5 No idea why it's complaining
CC: (none) => davidwhodgins
From: https://bugs.mageia.org/show_bug.cgi?id=18677#c7 After updates: [root@localhost wilcal]# urpmi graphicsmagick Package graphicsmagick-1.3.20-4.mga5.i586 is already installed [wilcal@localhost images_test]$ gm display pic1.ppm [wilcal@localhost images_test]$ gm display pic1_18.ppm Displays just fine install graphicsmagick from updates_testing [root@localhost wilcal]# urpmi graphicsmagick Package graphicsmagick-1.3.24-1.mga5.i586 is already installed [wilcal@localhost images_test]$ gm display pic1.ppm gm display: Unable to access configuration file (delegates.mgk) [No such file or directory]. gm display: Unable to open file (Untitled) [No such file or directory]. [wilcal@localhost images_test]$ gm display pic1_18.ppm gm display: Unable to access configuration file (delegates.mgk) [No such file or directory]. gm display: Unable to open file (Untitled) [No such file or directory].
Assigning back to Philippe for now, so we can look at adding the patch from Comment 37 and look into Bill's error in Comment 52.
Assignee: qa-bugs => makowski.mageia
(In reply to William Kenney from comment #52) > [wilcal@localhost images_test]$ gm display pic1.ppm > gm display: Unable to access configuration file (delegates.mgk) [No such > file or directory]. For what I understand it should look at : /usr/lib/GraphicsMagick-1.3.24/config/delegates.mgk or (for x86_64) /usr/lib64/GraphicsMagick-1.3.24/config/delegates.mgk running gm with "-debug configure" option should give some information I hope $gm display -debug configure pic1.ppm
LWN reference for CVE-2016-5241: http://lwn.net/Vulnerabilities/692029/ Fedora has issued an advisory for this on June 19: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/2AEZCYYFIENA7OTADHYBVNV5DKWIEGZP/
Removing MGA5-64-OK due to comment 51 and following
Whiteboard: feedback MGA5-64-OK => feedback
(In reply to David Walser from comment #37) > They have since added another commit fixing further SVG issues: > https://sourceforge.net/p/graphicsmagick/code/ci/ > 6071b5820215fb00f6395bf13f4b3109ea14b1de/ but no other distro include it (I checked Debian, OpenSuse and Fedora) and do you know how to get it as a patch ?
I rebuilt it (and moved a lib to solve comment #51): Updated packages in core/updates_testing: ======================== graphicsmagick-1.3.24-2.mga5 graphicsmagick-doc-1.3.24-2.mga5.noarch lib64graphicsmagick3-1.3.24-2.mga5 lib64graphicsmagick-devel-1.3.24-2.mga5 lib64graphicsmagickwand2-1.3.24-2.mga5 libgraphicsmagick3-1.3.24-2.mga5 libgraphicsmagick-devel-1.3.24-2.mga5 libgraphicsmagickwand2-1.3.24-2.mga5 perl-Graphics-Magick-1.3.24-2.mga5 from graphicsmagick-1.3.24-2.mga5.src.rpm $ gm display -debug configure /lib64/python2.7/test/imghdrdata/python.ppm 23:13:13 0:01 0.000u 9295 log.c/SetLogEventMask/1166/Configure: Set log event mask: configure 23:13:13 0:01 0.000u 9295 module.c/OpenModule/1454/Configure: Searching for module "PNM" using file name "pnm.so" 23:13:13 0:01 0.000u 9295 module.c/FindMagickModule/674/Configure: Searching for coder module file "pnm.so" ... 23:13:13 0:01 0.000u 9295 module.c/FindMagickModule/708/Configure: Searching for module file "pnm.so" in path "/usr/lib64/GraphicsMagick-1.3.24/modules-Q8/coders/" 23:13:13 0:01 0.000u 9295 utility.c/IsAccessible/2862/Configure: Found: /usr/lib64/GraphicsMagick-1.3.24/modules-Q8/coders/pnm.so 23:13:13 0:01 0.000u 9295 module.c/OpenModule/1476/Configure: Opening module at path "/usr/lib64/GraphicsMagick-1.3.24/modules-Q8/coders/pnm.so" ... 23:13:13 0:01 0.000u 9295 module.c/OpenModule/1512/Configure: Function "RegisterPNMImage" in module "PNM" at address 0x7f1c57cadb60 23:13:13 0:01 0.000u 9295 module.c/OpenModule/1529/Configure: Function "UnregisterPNMImage" in module "PNM" at address 0x7f1c57cadcb0 23:13:37 0:24 0.050u 9295 blob.c/GetConfigureBlob/1877/Configure: Searching for file "colors.mgk" in path "/usr/share/GraphicsMagick-1.3.24/config/:/usr/lib64/GraphicsMagick-1.3.24/config/" 23:13:37 0:24 0.050u 9295 blob.c/GetConfigureBlob/1900/Configure: Found: /usr/share/GraphicsMagick-1.3.24/config/colors.mgk 23:14:07 0:54 0.170u 9295 magick.c/DestroyMagick/170/Configure: Destroy Magick 23:14:07 0:54 0.170u 9295 module.c/UnloadModule/2190/Configure: Unloading "PNM" module ... $ gm display -debug configure /usr/share/gimp/2.0/gimpressionist/Brushes/cone.ppm 23:27:55 0:01 0.000u 9400 log.c/SetLogEventMask/1166/Configure: Set log event mask: configure 23:27:55 0:01 0.000u 9400 module.c/OpenModule/1454/Configure: Searching for module "PNM" using file name "pnm.so" 23:27:55 0:01 0.000u 9400 module.c/FindMagickModule/674/Configure: Searching for coder module file "pnm.so" ... 23:27:55 0:01 0.000u 9400 module.c/FindMagickModule/708/Configure: Searching for module file "pnm.so" in path "/usr/lib64/GraphicsMagick-1.3.24/modules-Q8/coders/" 23:27:55 0:01 0.000u 9400 utility.c/IsAccessible/2862/Configure: Found: /usr/lib64/GraphicsMagick-1.3.24/modules-Q8/coders/pnm.so 23:27:55 0:01 0.000u 9400 module.c/OpenModule/1476/Configure: Opening module at path "/usr/lib64/GraphicsMagick-1.3.24/modules-Q8/coders/pnm.so" ... 23:27:55 0:01 0.000u 9400 module.c/OpenModule/1512/Configure: Function "RegisterPNMImage" in module "PNM" at address 0x7f8fee07ab60 23:27:55 0:01 0.000u 9400 module.c/OpenModule/1529/Configure: Function "UnregisterPNMImage" in module "PNM" at address 0x7f8fee07acb0 23:27:59 0:04 0.030u 9400 magick.c/DestroyMagick/170/Configure: Destroy Magick 23:27:59 0:04 0.030u 9400 module.c/UnloadModule/2190/Configure: Unloading "PNM" module ... $ ls -la /usr/lib64/GraphicsMagick-1.3.24/config/ total 56 drwxr-xr-x 2 root root 4096 juin 21 22:50 ./ drwxr-xr-x 4 root root 4096 juin 21 22:50 ../ -rw-r--r-- 1 root root 6976 juin 21 22:43 delegates.mgk -rw-r--r-- 1 root root 10383 juin 21 22:43 type-ghostscript.mgk -rw-r--r-- 1 root root 86 juin 21 22:43 type.mgk -rw-r--r-- 1 root root 5253 juin 21 22:43 type-solaris.mgk -rw-r--r-- 1 root root 15792 juin 21 22:43 type-windows.mgk $ ls -la /usr/share/GraphicsMagick-1.3.24/config/ total 20 drwxr-xr-x 2 root root 4096 juin 21 22:50 ./ drwxr-xr-x 3 root root 4096 juin 21 22:50 ../ -rw-r--r-- 1 root root 497 juin 21 22:43 colors.mgk -rw-r--r-- 1 root root 2490 juin 21 22:43 log.mgk -rw-r--r-- 1 root root 439 juin 21 22:43 modules.mgk $ gm display /home/philippe/Images/circular.svg gm display: Negative or zero image size (/home/philippe/Images/circular.svg). $ gm display /home/philippe/Images/sigfpe.svg gm display: invalid primitive argument (-3.3976393189840888in).
Assignee: makowski.mageia => qa-bugs
(In reply to Philippe Makowski from comment #57) > (In reply to David Walser from comment #37) > > They have since added another commit fixing further SVG issues: > > https://sourceforge.net/p/graphicsmagick/code/ci/ > > 6071b5820215fb00f6395bf13f4b3109ea14b1de/ > > but no other distro include it (I checked Debian, OpenSuse and Fedora) So? They probably didn't notice it. > and do you know how to get it as a patch ? Copy and paste. Unfortunately sourceforge doesn't make it easy.
Hi, You can also try to use some mercurial commands: """ hg clone http://hg.code.sf.net/p/graphicsmagick/code graphicsmagick-code cd graphicsmagick-code hg log|less (to find the changeset, the part after the colon, here 6071b5820215) hg export -r 6071b5820215 -o ../test.diff """ And try to apply the patch (slightly modifying it if needed). Best regards, Nico.
Created attachment 8052 [details] Fix SVG issues (In reply to David Walser from comment #59) > Copy and paste. Unfortunately sourceforge doesn't make it easy. hg clone http://hg.code.sf.net/p/graphicsmagick/code graphicsmagick-code hg diff -c 6071b5820215fb00f6395bf13f4b3109ea14b1de > Fix_SVG_issues.patch then clean it
Comment on attachment 8052 [details] Fix SVG issues This patch can't apply on GraphicsMagick 1.3.24, seems that others changes are needed. Too much work Patch #2 (Fix_SVG_issues.patch): + /usr/bin/patch -p1 --fuzz=0 + /usr/bin/cat /home/philippe/mga/graphicsmagick/SOURCES/Fix_SVG_issues.patch patching file coders/svg.c patching file locale/C.mgk can't find file to patch at input line 28 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |--- a/magick/gm_messages.mc Mon May 30 12:07:20 2016 -0500 |+++ b/magick/gm_messages.mc Tue May 31 20:09:50 2016 -0500 -------------------------- File to patch: Skip this patch? [y] Skipping patch. 2 out of 2 hunks ignored patching file magick/locale_c.h patching file magick/render.c Hunk #3 FAILED at 2691. 1 out of 10 hunks FAILED -- saving rejects to file magick/render.c.rej patching file magick/utility.c Hunk #1 FAILED at 3724. 1 out of 2 hunks FAILED -- saving rejects to file magick/utility.c.rej
(In reply to Philippe Makowski from comment #62) > Comment on attachment 8052 [details] > Fix SVG issues > > This patch can't apply on GraphicsMagick 1.3.24, seems that others changes > are needed. > Too much work That doesn't make any sense. This was the first commit after the 1.3.24 release.
You can see the commits here: https://sourceforge.net/p/graphicsmagick/code/commit_browser In a later commit, he added this to the NEWS file: * SVG/MVG: Fix another case of CVE-2016-2317 (heap buffer overflow) in the MVG rendering code (also impacts SVG). Which I believe must refer to the commit in question (I can't see any other commit it could refer to), so you can see why I'd like to fix this.
In fact, that commit is not the first after the 1.3.24 release: - The 1.3.24 release was obtained from a branch starting at commit 8711e07, and whose parent commit is 557b69, but continuing with commits 59ed39, 418769 and 7d5e42. - Commit 6071b5 has commit 557b69 as parent, not commit 7d5e42.
Nicolas, I have no idea what you're talking about. There's some strange things going on in their version control system (I don't see where "* version.sh (PACKAGE_VERSION): Released 1.3.24." in the ChangeLog came from), but it was the first commit after 1.3.24 was tagged. The reason it didn't apply (besides the phantom additional line in the ChangeLog) was because either hg or bugzilla corrupted the patch in a few places, converting tabs to spaces, and because the gm_messages.mc file is not included in the tarball. The patch was easy to fix and I have committed it in SVN. I haven't pushed any builds yet, since the release tag in mga5 is wrong (should still be 1, with a subrel). We should have a sysadmin remove the current build in updates_testing so we can fix that.
I also just noticed that the major of the GraphicsMagick++ library has changed from 3 to 12, so the following packages will need to be rebuilt for this update: - gnudl - octave - pdf2djvu - photoqt In fact, octave needs to be rebuilt so that pfstools can be rebuilt for the imagemagick update (Bug 18598).
(In reply to David Walser from comment #66) > Nicolas, I have no idea what you're talking about. There's some strange > things going on in their version control system (I don't see where "* > version.sh (PACKAGE_VERSION): Released 1.3.24." in the ChangeLog came from), > but it was the first commit after 1.3.24 was tagged. I was not clear, sorry. What I would say is that the code contained in the tarball version 1.3.24 corresponds to commit 7d5e42, not commit 557b69. In the schema below, taken from https://sourceforge.net/p/graphicsmagick/code/commit_browser, we can see that commit 6071b5 comes from commit 557b69, not commit 7d5e42, so the patch applies cleanly for a source code corresponding to commit 557b69 but not necessarily for a source code corresponding to commit 7d5e42. * [6071b5] Fix SVG issues for files provided by Gustavo Grieco on May 31, 2016. | | * [7d5e42] Added tag GraphicsMagick-1_3_24 for changeset 41876934e762 | | | * [418769] Fix web page glitch. Fix accidential reversion of autotools ... | | | * [59ed39] Added tag GraphicsMagick-1_3_24 for changeset 8711e07cdebe | | | * [8711e0] Merge changes for 1.3.24 release. |/ * [557b69] Updates to prepare for 1.3.24 release.
(In reply to Nicolas Salguero from comment #68) > I was not clear, sorry. What I would say is that the code contained in the > tarball version 1.3.24 corresponds to commit 7d5e42, not commit 557b69. > > In the schema below, taken from > https://sourceforge.net/p/graphicsmagick/code/commit_browser, we can see > that commit 6071b5 comes from commit 557b69, not commit 7d5e42, so the patch > applies cleanly for a source code corresponding to commit 557b69 but not > necessarily for a source code corresponding to commit 7d5e42. Thanks, I see what you're saying now. Fortunately, the only changes in that branch that affected anything were just that one added line in the ChangeLog, so the patch otherwise does apply cleanly. While you're looking at it, do you agree that the: "* SVG/MVG: Fix another case of CVE-2016-2317 (heap buffer overflow) in the MVG rendering code (also impacts SVG)." later added in the NEWS must refer to commit 6071b5, as it couldn't be referring to anything else? I just find it strange that the NEWS item talks about MVG when the commit talks about SVG, but I don't see any other MVG-related changes in between.
(In reply to David Walser from comment #69) > While you're looking at it, do you agree that the: > "* SVG/MVG: Fix another case of CVE-2016-2317 (heap buffer overflow) in > the MVG rendering code (also impacts SVG)." > > later added in the NEWS must refer to commit 6071b5, as it couldn't be > referring to anything else? Yes, for me too, it refers to commit 6071b5.
Philippe, can we can an updated advisory? It should mention: Also, the gnudl, octave, pdf2djvu, and photoqt packages have been rebuilt to use the updated GraphicsMagick++ library. Updated packages in core/updates_testing: ======================== graphicsmagick-1.3.24-1.1.mga5 graphicsmagick-doc-1.3.24-1.1.mga5.noarch lib64graphicsmagick3-1.3.24-1.1.mga5 lib64graphicsmagick-devel-1.3.24-1.1.mga5 lib64graphicsmagickwand2-1.3.24-1.1.mga5 libgraphicsmagick3-1.3.24-1.1.mga5 libgraphicsmagick-devel-1.3.24-1.1.mga5 libgraphicsmagickwand2-1.3.24-1.1.mga5 perl-Graphics-Magick-1.3.24-1.1.mga5 gnudl-0.9.5-2.1.mga5 octave-3.8.2-3.1.mga5 octave-devel-3.8.2-3.1.mga5 octave-doc-3.8.2-3.1.mga5 pdf2djvu-0.7.17-4.1.mga5 photoqt-1.0-4.1.mga5 from SRPMS: graphicsmagick-1.3.24-1.1.mga5.src.rpm gnudl-0.9.5-2.1.mga5.src.rpm octave-3.8.2-3.1.mga5.src.rpm pdf2djvu-0.7.17-4.1.mga5.src.rpm photoqt-1.0-4.1.mga5.src.rpm
Whiteboard: feedback => (none)
Philippe, this change was incorrect and should be reverted: http://svnweb.mageia.org/packages/updates/5/graphicsmagick/current/SPECS/graphicsmagick.spec?r1=1037138&r2=1037137&pathrev=1037138
(In reply to David Walser from comment #72) > Philippe, this change was incorrect and should be reverted: > http://svnweb.mageia.org/packages/updates/5/graphicsmagick/current/SPECS/ > graphicsmagick.spec?r1=1037138&r2=1037137&pathrev=1037138 hum, but in mga5, before upgrade to 1.3.24, %{_libdir}/libGraphicsMagick++.so.%{ppmajor}* was in %{libname} and if I revert, we have to add some conflict, if not, we have issue reported in comment #51
(In reply to Philippe Makowski from comment #73) > hum, but in mga5, before upgrade to 1.3.24, > %{_libdir}/libGraphicsMagick++.so.%{ppmajor}* was in %{libname} > and if I revert, we have to add some conflict, if not, we have issue > reported in > comment #51 No, by putting the lib with a different major back into that other lib package, you *caused* a conflict that will cause upgrade issues. The reason Comment 51 happened is that pdf2djvu and the other package built against GraphicsMagick++ hadn't been rebuilt against the new library with the newer major number. I have since rebuilt them.
Advisory: ======================== Updated graphicsmagick package fixes security vulnerability: - A read out-of-bound in the parsing of gif files using GraphicsMagick (CVE-2015-8808). - Infinite loop caused by converting a circularly defined svg file (CVE-2016-2317). Fix another case of CVE-2016-2317 (heap buffer overflow) in the MVG rendering code (also impacts SVG). - Arithmetic exception converting a svg file caused by a X%0 operation in magick/render.c (CVE-2016-2318) - A shell exploit (CVE-2016-5118) was discovered associated with a filename syntax where file names starting with '|' are intepreted as shell commands executed via popen(). Insufficient sanitization in the SVG and MVG renderers allows such filenames to be passed through from potentially untrusted files. There might be other ways for untrusted inputs to produce such filenames. Due to this issue, support for the feature is removed entirely. gnudl, octave, pdf2djvu, and photoqt packages have been rebuilt to use the updated GraphicsMagick++ library. References: - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2317 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2318 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8808 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5118 - http://openwall.com/lists/oss-security/2016/05/01/6 - http://openwall.com/lists/oss-security/2016/02/06/3 - http://lwn.net/Vulnerabilities/677107/ - http://openwall.com/lists/oss-security/2016/05/30/1 - http://www.graphicsmagick.org/NEWS.html Updated packages in core/updates_testing: ======================== graphicsmagick-1.3.24-1.2.mga5 graphicsmagick-doc-1.3.24-1.2.mga5.noarch lib64graphicsmagick++12-1.3.24-1.2.mga5 lib64graphicsmagick3-1.3.24-1.2.mga5 lib64graphicsmagick-devel-1.3.24-1.2.mga5 lib64graphicsmagickwand2-1.3.24-1.2.mga5 libgraphicsmagick3-1.3.24-1.2.mga5 libgraphicsmagick++12-1.3.24-1.2.mga5 libgraphicsmagick-devel-1.3.24-1.2.mga5 libgraphicsmagickwand2-1.3.24-1.2.mga5 perl-Graphics-Magick-1.3.24-1.2.mga5 gnudl-0.9.5-2.1.mga5 octave-3.8.2-3.1.mga5 octave-devel-3.8.2-3.1.mga5 octave-doc-3.8.2-3.1.mga5 pdf2djvu-0.7.17-4.1.mga5 photoqt-1.0-4.1.mga5 from SRPMS: graphicsmagick-1.3.24-1.2.mga5.src.rpm gnudl-0.9.5-2.1.mga5.src.rpm octave-3.8.2-3.1.mga5.src.rpm pdf2djvu-0.7.17-4.1.mga5.src.rpm photoqt-1.0-4.1.mga5.src.rpm
Thanks Philippe. The advisory is missing the new CVEs in Comment 38 (also see Comment 55).
Advisory: ======================== Updated graphicsmagick package fixes security vulnerability: - A read out-of-bound in the parsing of gif files using GraphicsMagick (CVE-2015-8808). - Infinite loop caused by converting a circularly defined svg file (CVE-2016-5240). Fix another case of CVE-2016-2317 (heap buffer overflow) in the MVG rendering code (also impacts SVG). - arithmetic exception converting a svg file (CVE-2016-5241) - Arithmetic exception converting a svg file caused by a X%0 operation in magick/render.c (CVE-2016-2318) - A shell exploit (CVE-2016-5118) was discovered associated with a filename syntax where file names starting with '|' are intepreted as shell commands executed via popen(). Insufficient sanitization in the SVG and MVG renderers allows such filenames to be passed through from potentially untrusted files. There might be other ways for untrusted inputs to produce such filenames. Due to this issue, support for the feature is removed entirely. gnudl, octave, pdf2djvu, and photoqt packages have been rebuilt to use the updated GraphicsMagick++ library. References: - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2317 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2318 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8808 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5118 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5241 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5240 - http://openwall.com/lists/oss-security/2016/05/01/6 - http://openwall.com/lists/oss-security/2016/02/06/3 - http://lwn.net/Vulnerabilities/677107/ - http://openwall.com/lists/oss-security/2016/05/30/1 - http://www.graphicsmagick.org/NEWS.html Updated packages in core/updates_testing: ======================== graphicsmagick-1.3.24-1.2.mga5 graphicsmagick-doc-1.3.24-1.2.mga5.noarch lib64graphicsmagick++12-1.3.24-1.2.mga5 lib64graphicsmagick3-1.3.24-1.2.mga5 lib64graphicsmagick-devel-1.3.24-1.2.mga5 lib64graphicsmagickwand2-1.3.24-1.2.mga5 libgraphicsmagick3-1.3.24-1.2.mga5 libgraphicsmagick++12-1.3.24-1.2.mga5 libgraphicsmagick-devel-1.3.24-1.2.mga5 libgraphicsmagickwand2-1.3.24-1.2.mga5 perl-Graphics-Magick-1.3.24-1.2.mga5 gnudl-0.9.5-2.1.mga5 octave-3.8.2-3.1.mga5 octave-devel-3.8.2-3.1.mga5 octave-doc-3.8.2-3.1.mga5 pdf2djvu-0.7.17-4.1.mga5 photoqt-1.0-4.1.mga5 from SRPMS: graphicsmagick-1.3.24-1.2.mga5.src.rpm gnudl-0.9.5-2.1.mga5.src.rpm octave-3.8.2-3.1.mga5.src.rpm pdf2djvu-0.7.17-4.1.mga5.src.rpm photoqt-1.0-4.1.mga5.src.rpm
Blocks: (none) => 18598
Testing on x86_64 hardware. Just the graphicsmagick tests to start with, before and after the updates. All the suggested tests worked except for those concerned with tiff images which had been converted from jpeg format. These invariably issued a notice like: gm display: abc004.tiff: Invalid tag "BadFaxLines" (not supported by codec). (_TIFFVSetField). TIFFs generated from gif and png files were perfectly OK. Note this also: $ gm convert BenBois_Clock.svg clock.tiff gm convert: Non-conforming drawing primitive definition (push). $ gm convert BenBois_Clock.svg clock.jpg gm convert: Non-conforming drawing primitive definition (push). The DoS may have been fixed - I can't tell, but the http://openwall.com/lists/oss-security/2016/05/01/6 reference concerns SVG files.
Additional tests after updates. $ octave octave:1> doc error: doc: unable to find the Octave info manual, Octave installation is incomplete octave:1> exit 'man octave' and --help are available. It needs a mathematician for proper testing. photoqt is an immersive image viewer and seems to work fine. $ pdf2djvu -o whatever.xyz referendum.pdf referendum.pdf: - page #1 -> #1 - page #2 -> #2 - page #3 -> #3 - page #4 -> #4 0.020 bits/pixel; 5.405:1, 81.50% saved, 469046 bytes in, 86783 bytes out [lcl@vega ~/docs]$ file whatever.xyz whatever.xyz: DjVu multiple page document Presumably there is an application to display the output - it is not djvu or dejavu or LibreOffice. The file extension should probably be .djv or .djvu The applications look OK.
SVG PoC here: http://www.openwall.com/lists/oss-security/2016/05/29/7
Thanks Claire. I had seen that but did not understand the svg bit. Had already run the simple hello.txt test. Took another look and checked an existing svg image to see if it was readable and sure enough it looks like an XML document. Copied the supplied text into test.svg: <?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="4in" height="3in" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> <desc>Illustrates how a shell command may be embedded in a SVG. </desc> <image x="200" y="200" width="100px" height="100px" xlink:href="|echo Hello > hello.txt; cat /usr/lib/firefox/browser/icons/mozicon128.png"> <title>My image</title> </image> </svg> and $ gm display test.svg gm display: Unable to open file (|echo Hello > hello.txt; cat /usr/lib/firefox/browser/icons/mozicon128.png) [No such file or directory]. gm display: Unable to open file (|echo Hello > hello.txt; cat /usr/lib/firefox/browser/icons/mozicon128.png) [No such file or directory]. I guess that does show that the fix worked. Repeated the jpeg -> tiff conversion, comparing with ImageMagick. $ convert bbc2.jpg bbc2.tiff $ gm display bbc2.jpg $ gm display bbc2.tiff $ gm convert bbc2.jpg bbc2.tiff gm convert: bbc2.tiff: Invalid tag "BadFaxLines" (not supported by codec). (_TIFFVGetField). $ display bbc2.tiff display: bbc2.tiff: Invalid tag "Predictor" (not supported by codec). `_TIFFVSetField' @ error/tiff.c/TIFFErrors/561. display: bbc2.tiff: Invalid tag "BadFaxLines" (not supported by codec). `_TIFFVSetField' @ error/tiff.c/TIFFErrors/561. However, the image is displayed correctly. gm is fussier. $ gm display bbc2.tiff gm display: bbc2.tiff: Invalid tag "BadFaxLines" (not supported by codec). (_TIFFVSetField). No image.
Good testing Len. Adding the OK.
Whiteboard: (none) => mga5-64-ok
CC: lewyssmith => (none)
Keywords: (none) => validated_updateWhiteboard: mga5-64-ok => mga5-64-ok advisoryCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2016-0252.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
LWN reference for CVE-2015-8808: http://lwn.net/Vulnerabilities/694626/
That SVG/MVG issue fixed after 1.3.24 that I added the patch for in this update has been assigned CVE-2016-7446: http://openwall.com/lists/oss-security/2016/09/18/8