A Debian bug report [1] indicated that ImageMagick would load configuration files from the current working directory, rather than just standard directories like ~/.magick/ or /usr/lib/ImageMagick-*/config/. If a user were to run certain ImageMagick programs, like the convert utility, from untrusted directories it could allow for the execution of arbitrary code as the user running the program. Upstream has corrected [2] this flaw is noted as being fixed in the 6.6.5-5 ChangeLog [3]. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601824 [2] http://trac.imagemagick.org/changeset?new=3022%40ImageMagick%2Ftrunk%2Fmagick%2Fconfigure.c&old=2002%40ImageMagick%2Ftrunk%2Fmagick%2Fconfigure.c [3] http://trac.imagemagick.org/browser/ImageMagick/trunk/ChangeLog
The Debian bug report has some sample files used to demonstrate the problem. I've reproduced this on Fedora using those sample files, but not on RHEL4 or 5. Looking at strace output from ImageMagick on RHEL5, it's definitely opening files in $CWD, but is not parsing these XML files (perhaps they are in a different format than the older ImageMagick expected or there is something else preventing the execution, I didn't spend much time poking at it). open("/usr/share/ImageMagick-6.2.8/config/delegates.xml", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/share/doc/ImageMagick-6.2.8/delegates.xml", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/share/ImageMagick-6.2.8/delegates.xml", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/home/vdanen/.magick/delegates.xml", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("delegates.xml", O_RDONLY|O_LARGEFILE) = 3 _llseek(3, 0, [105], SEEK_END) = 0 The upstream patch does apply, with fuzz, to RHEL5 at least.
The vulnerable code is in configure.c (line 722) in ImageMagick-6.2.8.0-4.el5_5.3.src.rpm, I would assume it's in the updates as well.
This has been assigned the name CVE-2010-4167.
Created ImageMagick tracking bugs for this issue Affects: fedora-all [bug 653577]
If it low impact and fixed upstream may it be closed as UPSTREAM? And when I'll push next update it will fix it automatically.
(In reply to comment #6) > If it low impact and fixed upstream may it be closed as UPSTREAM? > > And when I'll push next update it will fix it automatically. You could do that for the Fedora tracker, but we'd prefer if the bug was actually closed when an update is pushed to Fedora. As this also affects RHEL, and will not be fixed automatically with a Fedora update, this bug cannot be closed until it is addressed in RHEL.
In rawhide new version 6.6.5.10 which shouldn't be affected.
No answer. I Assume problem fixed.
This bug should not be closed.
Why?
There are affected ImageMagick versions in RHEL that are planned to be corrected in some future update (as was previously explained in comment #7). Feel free to un-CC yourself if you only care about Fedora package, which you've dealt with already. Thank you.
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2012:0301 https://rhn.redhat.com/errata/RHSA-2012-0301.html
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2012:0544 https://rhn.redhat.com/errata/RHSA-2012-0544.html
Statement: (none)