First Last Prev Next    This bug is not in your last search results.
Bug 1087820 - (CVE-2018-9133) VUL-1: CVE-2018-9133: ImageMagick: ImageMagick 7.0.7-26 Q16 has excessive iteration in the DecodeLabImage andEncodeLabImage functions (coders/tiff.c), which results in a hang (tens ofminutes) with a tiny PoC file. Remote at
(CVE-2018-9133)
VUL-1: CVE-2018-9133: ImageMagick: ImageMagick 7.0.7-26 Q16 has excessive ite...
Status: RESOLVED FIXED
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P4 - Low : Normal
: ---
Assigned To: Security Team bot
Security Team bot
https://smash.suse.de/issue/203008/
CVSSv3:SUSE:CVE-2018-9133:6.2:(AV:L/A...
:
Depends on:
Blocks:
  Show dependency tree / graph
 
Reported: 2018-04-03 06:07 UTC by Marcus Meissner
Modified: 2018-06-30 14:37 UTC (History)
4 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Attachments
imagemagick_7-0-7_mogrify_excessive-iteration_DecodeLabImage.tiff (108 bytes, application/octet-stream)
2018-04-03 06:22 UTC, Marcus Meissner 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Meissner 2018-04-03 06:07:36 UTC 
CVE-2018-9133

ImageMagick 7.0.7-26 Q16 has excessive iteration in the DecodeLabImage and
EncodeLabImage functions (coders/tiff.c), which results in a hang (tens of
minutes) with a tiny PoC file. Remote attackers could leverage this
vulnerability to cause a denial of service via a crafted tiff file.

References:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-9133
http://people.canonical.com/~ubuntu-security/cve/2018/CVE-2018-9133.html
Comment 1 Marcus Meissner 2018-04-03 06:08:20 UTC 
https://github.com/ImageMagick/ImageMagick/issues/1072
Comment 2 Marcus Meissner 2018-04-03 06:22:47 UTC 
Created attachment 765725 [details]
imagemagick_7-0-7_mogrify_excessive-iteration_DecodeLabImage.tiff

QA REPRODUCER:

convert imagemagick_7-0-7_mogrify_excessive-iteration_DecodeLabImage.tiff foo.jpg

should not take very long.
Comment 3 Marcus Meissner 2018-04-03 06:24:48 UTC 
GraphicsMagick seems to have sufficient checks for this, not exploitable out of the box.

Imagemagick can fill the harddisk rapidly, SLE12 and Tumbleweed seem affected.
SLE11 IM reports errors on the format.
Comment 4 Petr Gajdos 2018-04-11 10:43:24 UTC 
BEFORE

12/ImageMagick

$ mogrify imagemagick_7-0-7_mogrify_excessive-iteration_DecodeLabImage.tiff&
[1] 23087
$ du -hs /tmp/magick-23087bvZ6wPh1uo93 
1.8G	/tmp/magick-23087bvZ6wPh1uo93
$ du -hs /tmp/magick-*
2.2G	/tmp/magick-23087bvZ6wPh1uo93
$ du -hs /tmp/magick-*
2.4G	/tmp/magick-23087bvZ6wPh1uo93
$ du -hs /tmp/magick-*
2.4G	/tmp/magick-23087bvZ6wPh1uo93
$
[as Marcus says]

11/ImgeMagick

$ mogrify imagemagick_7-0-7_mogrify_excessive-iteration_DecodeLabImage.tiff
$
[no issues observed]

11/GraphicsMagick

$ gm mogrify imagemagick_7-0-7_mogrify_excessive-iteration_DecodeLabImage.tiff 
gm mogrify: Unable to read CIELAB images (imagemagick_7-0-7_mogrify_excessive-iteration_DecodeLabImage.tiff).
$
[format not supported at all, no issues observed]

42.3/GraphicsMagick

$ gm mogrify imagemagick_7-0-7_mogrify_excessive-iteration_DecodeLabImage.tiff 
gm mogrify: Insufficient image data in file (imagemagick_7-0-7_mogrify_excessive-iteration_DecodeLabImage.tiff).
$
[file checked for data amount, no issues observed]


PATCH

https://github.com/ImageMagick/ImageMagick/commit/089fca04e0130549fa15f48ace3f56e30a06049a

12/ImageMagick: affected
11/ImageMagick: no special handling of PHOTOMETRIC_CIELAB, {De,En}codeLabImage missing; considering not affected
*/GraphicsMagick: considering not affected for the same reason

Unfortunately the patch above nor the latest version of tiff.c with latest 7.0.7-28 does not seem to prevent the behavior described in comment 0 or upstream bug. I will wait for 7.0.7-29 and when I will reproduce it, I will report upstream.

I think potential solution could be to check sizes of image against file size.
Comment 5 Petr Gajdos 2018-05-09 12:45:30 UTC 
Still the same issue as described in comment 4. Reported upstream:
https://github.com/ImageMagick/ImageMagick/issues/1127
Comment 6 Petr Gajdos 2018-05-22 10:29:27 UTC 
If I understand upstream explanation correctly, such a TIFF (big dimensions but small file size) can be a valid TIFF file and the behavior in comment 4, 12/ImageMagick section is expected.

Explanation. Maybe more clear example is following SVG:

<svg>
    <rect x="10" y="10" height="100000" width="100000"
          style="stroke:#ff0000; fill: #0000ff"/>
</svg>

I get with 7.0.7-29:

$ convert test.svg test.png
[the same behavior as in comment 4, 12/ImageMagick section]

whereas

$ convert -limit disk 1GB test.svg test.png
convert: cache resources exhausted `test.svg' @ error/cache.c/OpenPixelCache/3663.
convert: no decode delegate for this image format `test.svg' @ error/svg.c/ReadSVGImage/3198.
convert: no images defined `test.png' @ error/convert.c/ConvertImageCommand/3275.
$

or

$ convert -limit time 1s test.svg test.png
convert: time limit exceeded `Operation canceled' @ fatal/cache.c/GetImagePixelCache/1607.
unable to destroy mutex: Device or resource busy
$

I think the important part is, that policy settings cannot be circumvented.

What was my ignorance is, that TIFF can expose the same issue (big dimensions but small file size). From the upstream reply implies that it can; for 12/tiff I get BEFORE:

$ mogrify -limit disk 1GB imagemagick_7-0-7_mogrify_excessive-iteration_DecodeLabImage.tiff
087820: DistributedPixelCache '127.0.0.1' @ error/distribute-cache.c/ConnectPixelCacheServer/215.
087820: cache resources exhausted `imagemagick_7-0-7_mogrify_excessive-iteration_DecodeLabImage.tiff' @ error/cache.c/OpenPixelCache/3631.
087820: DistributedPixelCache '127.0.0.1' @ error/distribute-cache.c/ConnectPixelCacheServer/215.
087820: cache resources exhausted `imagemagick_7-0-7_mogrify_excessive-iteration_DecodeLabImage.tiff' @ error/cache.c/OpenPixelCache/3631.
$

$ mogrify -limit time 1s imagemagick_7-0-7_mogrify_excessive-iteration_DecodeLabImage.tiff
mogrify: time limit exceeded `File exists' @ fatal/cache.c/GetImagePixelCache/1496.
unable to destroy mutex: Device or resource busy
$

In contrast to newest versions of ImageMagick, 12/ImageMagick/mogrify seem to just trying to contact pixel cache server but the policy is not circumvented. Furthermore, gdb does not stop at all at EncodeLabImage() with or without -limit disk 1GB.

To sum up, I believe the testcase does not expose the original issue for me and seem to have the same consequences BEFORE and AFTER. The patch can be accepted, though as the same code is in 12/ImageMagick.
Comment 7 Petr Gajdos 2018-05-22 10:31:45 UTC 
Will submit for 12/tiff.
Comment 8 Petr Gajdos 2018-05-22 10:32:26 UTC 
This should obviously have been: will submit for 12/ImageMagick.
Comment 9 Petr Gajdos 2018-05-22 10:35:06 UTC 
Package submitted.
Comment 13 Alexei Tighineanu 2018-06-15 10:03:20 UTC 
Looks like on SLE 12 sp3 this isn't fixed:

        BEFORE (the update):
        levante:~ # rpm -qi ImageMagick | egrep -i "version|release"
        Version     : 6.8.8.1
        Release     : 71.54.5
         ===
         levante:~ # convert imagemagick_7-0-7_mogrify_excessive-iteration_DecodeLabImage.tiff foo.jpg
        (gets stuck...)

        AFTER (the update):
        levante:~ # rpm -qi ImageMagick | egrep -i "version|release"
        Version     : 6.8.8.1
        Release     : 71.61.1
        ===
        levante:~ # convert imagemagick_7-0-7_mogrify_excessive-iteration_DecodeLabImage.tiff foo.jpg
        (gets stuck...)


levante:~ # cat /etc/os-release 
NAME="SLED"
VERSION="12-SP3"
VERSION_ID="12.3"
PRETTY_NAME="SUSE Linux Enterprise Desktop 12 SP3"
ID="sled"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sled:12:sp3"
Comment 18 jun wang 2018-06-26 09:08:35 UTC 
Looks like on SLE 12 sp3 this isn't fixed:

# convert imagemagick_7-0-7_mogrify_excessive-iteration_DecodeLabImage.tiff foo.jpg
[hang]

I am testing ImageMagick (ID: SUSE:Maintenance:7537:167416),
but I got the above result BEFORE and AFTER.

please check it.
Comment 19 Petr Gajdos 2018-06-27 08:28:34 UTC 
Please read comment 6, thanks.
Comment 20 jun wang 2018-06-27 08:33:47 UTC 
(In reply to Petr Gajdos from comment #19)
> Please read comment 6, thanks.

Oh, that's it.
sorry for my carelessness.
Thank you Petr.
Comment 21 Swamp Workflow Management 2018-06-29 19:08:45 UTC 
SUSE-SU-2018:1851-1: An update that fixes 8 vulnerabilities is now available.

Category: security (moderate)
Bug References: 1047356,1056277,1087820,1094204,1094237,1095730,1095812,1095813
CVE References: CVE-2017-10928,CVE-2017-13758,CVE-2017-18271,CVE-2018-10804,CVE-2018-10805,CVE-2018-11251,CVE-2018-11655,CVE-2018-9133
Sources used:
SUSE Linux Enterprise Workstation Extension 12-SP3 (src):    ImageMagick-6.8.8.1-71.65.1
SUSE Linux Enterprise Software Development Kit 12-SP3 (src):    ImageMagick-6.8.8.1-71.65.1
SUSE Linux Enterprise Server 12-SP3 (src):    ImageMagick-6.8.8.1-71.65.1
SUSE Linux Enterprise Desktop 12-SP3 (src):    ImageMagick-6.8.8.1-71.65.1
Comment 22 Andreas Stieger 2018-06-30 09:45:04 UTC 
release for Leap, showing as done
Comment 23 Swamp Workflow Management 2018-06-30 13:09:17 UTC 
openSUSE-SU-2018:1860-1: An update that fixes 8 vulnerabilities is now available.

Category: security (moderate)
Bug References: 1047356,1056277,1087820,1094204,1094237,1095730,1095812,1095813
CVE References: CVE-2017-10928,CVE-2017-13758,CVE-2017-18271,CVE-2018-10804,CVE-2018-10805,CVE-2018-11251,CVE-2018-11655,CVE-2018-9133
Sources used:
openSUSE Leap 42.3 (src):    ImageMagick-6.8.8.1-64.1
First Last Prev Next    This bug is not in your last search results.