Bug 1033361 - (CVE-2017-7619) VUL-0: CVE-2017-7619: ImageMagick: an infinite loop can occur because of a floating-point rounding error in some of the color algorithms
VUL-0: CVE-2017-7619: ImageMagick: an infinite loop can occur because of a fl...
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
Other Other
: P3 - Medium : Normal
: unspecified
Assigned To: Security Team bot
Security Team bot
Depends on:
  Show dependency treegraph
Reported: 2017-04-10 17:35 UTC by Mikhail Kasimov
Modified: 2017-09-14 22:39 UTC (History)
3 users (show)

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

patch against sle11 version (1.72 KB, patch)
2017-04-18 11:38 UTC, Petr Gajdos
Details | Diff
patch against GraphicsMagick, sle11 version (596 bytes, patch)
2017-04-18 13:30 UTC, Petr Gajdos
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mikhail Kasimov 2017-04-10 17:35:12 UTC
Ref: https://nvd.nist.gov/vuln/detail/CVE-2017-7619

In ImageMagick 7.0.4-9, an infinite loop can occur because of a floating-point rounding error in some of the color algorithms. This affects ModulateHSL, ModulateHCL, ModulateHCLp, ModulateHSB, ModulateHSI, ModulateHSV, ModulateHWB, ModulateLCHab, and ModulateLCHuv.

Source:  MITRE      Last Modified:  04/10/2017


[1] https://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=31506

(open-)SUSE: https://software.opensuse.org/package/ImageMagick (TW, official repo) (42.{1,2}, official repo)
Comment 2 Alexander Bergmann 2017-04-12 07:56:40 UTC
git fix from comment 1 can be applied to SLE-12:Update without any problems. 

SLE-11:Update has some of the code snippets that got changed in SLE-12. Most of the changes cannot be applied. Not sure if the present parts need to be fixed.
Comment 3 Petr Gajdos 2017-04-18 10:42:17 UTC
How I reproduced on sle12 (for sle11 would be the same, but it does not accept E-notation, so one needs to use zeroes instead):

1. take an image, for example 
2. run
$ convert rose.png -modulate 100,100,1E25 rose-mod.png
3. see the convert runs 'forever'

But it is not forever actually:

$ time convert rose.png -modulate 100,100,1000000 rose-mod.png

real	0m0.012s
user	0m0.024s
sys	0m0.000s
$ time convert rose.png -modulate 100,100,10000000 rose-mod.png

real	0m0.045s
user	0m0.180s
sys	0m0.000s
$ time convert rose.png -modulate 100,100,100000000 rose-mod.png

real	0m0.311s
user	0m1.748s
sys	0m0.000s
$ time convert rose.png -modulate 100,100,1000000000 rose-mod.png

real	0m2.356s
user	0m17.916s
sys	0m0.036s
$ time convert rose.png -modulate 100,100,10000000000 rose-mod.png

real	0m22.872s
user	2m55.020s
sys	0m0.000s

With 7.0.5-4 (fix included there) I get:

$ time convert rose.png -modulate 100,100,1E25 rose-mod.png

real	0m0.009s
user	0m0.008s
sys	0m0.000s

It looks like this is good improvement, but I am not sure where the root of the security impact lies. In my opinion: adding a large parameter on the command line provoking long processing can be expected. 

For the same reason, also

$ php -r '$fact = gmp_fact(100000000); echo gmp_strval($fact) . "\n";'

could be treated as a security issue, too, because it just takes so long. Please reconsider if this is a security issue of ImageMagick. If somewhere, it should be checked in another layer I think.

By the way: tested the patch from comment 1 and it fixes it for sle12, yes
Comment 4 Petr Gajdos 2017-04-18 11:38:38 UTC
Created attachment 721610 [details]
patch against sle11 version
Comment 5 Petr Gajdos 2017-04-18 13:30:44 UTC
Created attachment 721616 [details]
patch against GraphicsMagick, sle11 version

Tested both before (same symptoms) and after (fixed).
Comment 6 Marcus Meissner 2017-06-01 15:25:25 UTC
not yet in any submissions.

i do not think this is a valid security issue
Comment 7 Marcus Meissner 2017-08-25 12:41:30 UTC
marking invalid