ImageMagick before 7.0.5-2 uses uninitialized memory in the RLE decoder, allowing an attacker to leak sensitive information from process memory space, as demonstrated by remote attacks against ImageMagick code in a long-running server process that converts image data on behalf of multiple users. This is caused by a missing initialization step in the ReadRLEImage function in coders/rle.c. Upstream patch: https://github.com/ImageMagick/ImageMagick/commit/1c358ffe0049f768dd49a8a889c1cbf99ac9849b External References: https://scarybeastsecurity.blogspot.com/2017/05/bleed-continues-18-byte-file-14k-bounty.html
Created ImageMagick tracking bugs for this issue: Affects: fedora-all [bug 1453125]
References: http://seclists.org/oss-sec/2017/q2/302
When reading RLE images, ImageMagick uses a chunk of heap memory to store the image's pixel values. The problem is that this chunk of memory is not properly initialized (for example reset to only contain 0 bytes) before being used, thus said chunk could contain "live" heap memory instead of data loaded from the RLE image file. This can be a problem, as subsequent processing (e.g. storing it back on disk) could lead to the disclosure of heap memory contents, if the resulting image is shared with the attacker or other untrusted parties. The exact impact depends on the circumstances and the way ImageMagick is used: - If you do not allow RLE images to be processed you are not affected. - If you only process images from trusted sources, or do not disclose any of the images created by ImageMagick outside of trusted parties, the leak should be contained by those trust boundaries. - If you spawn a new process for every image processed (for example, you run the "convert" binary for each image) and don't do anything special apart from that, it's unlikely that anything of interest will be leaked. - If you use ImageMagick as part of a longer running process and ImageMagick image processing shares the heap memory with your application, it's possible that heap memory contents could be disclosed. The exact impact then depends on what exactly is stored in the heap memory.
Mitigation: Forcefully disable the RLE decoder from being used, for example by renaming ImageMagick's rle.so library: RHEL6 mitigation: 32bit: mv /usr/lib/ImageMagick-6.7.2/modules-Q16/coders/rle.so /usr/lib/ImageMagick-6.7.2/modules-Q16/coders/rle.so.CVE-2017-9098 64bit: mv /usr/lib64/ImageMagick-6.7.2/modules-Q16/coders/rle.so /usr/lib64/ImageMagick-6.7.2/modules-Q16/coders/rle.so.CVE-2017-9098 RHEL7 mitigation: 32bit: mv /usr/lib/ImageMagick-6.7.8/modules-Q16/coders/rle.so /usr/lib/ImageMagick-6.7.8/modules-Q16/coders/rle.so.CVE-2017-9098 64bit: mv /usr/lib64/ImageMagick-6.7.8/modules-Q16/coders/rle.so /usr/lib64/ImageMagick-6.7.8/modules-Q16/coders/rle.so.CVE-2017-9098 If you are using the glibc heap implementation (default), it may also be possible to set the "MALLOC_PERTURB_" environment variable to a non-zero value before launching the process using ImageMagick. This should forcefully initialize the memory, but may reduce performance. Ensure proper testing before using these methods.
Statement: Red Hat Product Security has rated this issue as having Moderate security impact. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.