Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect parsing Cineon causing convert to take ridiculous time #1472

Closed
3 tasks done
hongxuchen opened this issue Feb 5, 2019 · 7 comments
Closed
3 tasks done

Incorrect parsing Cineon causing convert to take ridiculous time #1472

hongxuchen opened this issue Feb 5, 2019 · 7 comments

Comments

@hongxuchen
Copy link

Prerequisites

  • I have written a descriptive issue title
  • I have verified that I am using the latest version of ImageMagick
  • I have searched open and closed issues to ensure it has not already been reported

Description

Cineon image may be mistakenly parsed with incorrect pixel information, causing converting to take too much CPU resource.

Steps to Reproduce

convert c.cin /tmp/test.tmp

work/imagemagick > gdb --args ./ImageMagick-orig/install/bin/convert ./convert-report/c.cin /tmp/test.bmp
Reading symbols from ./ImageMagick-orig/install/bin/convert...done.
gdb$ run
Starting program: /home/ubuntu/work/imagemagick/ImageMagick-orig/install/bin/convert ./convert-report/c.cin /tmp/test.bmp
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
^C
Program received signal SIGINT, Interrupt.
SetImageBackgroundColor (image=0x63aab0, exception=0x6244d0) at MagickCore/image.c:2464
2464          q+=GetPixelChannels(image);
gdb$ b MagickCore/image.c:2464
Breakpoint 1 at 0x7ffff777ed88: file MagickCore/image.c, line 2464.
gdb$ p image->columns
$1 = 0x40002
gdb$ p image->Quitmns
gdb$ display image->columns
1: image->columns = 0x40002
gdb$ display image->rows
2: image->rows = 0x70000
gdb$ display x
3: x = 0x1bd43
gdb$ display y
4: y = 0x21d
gdb$ c 100
Not stopped at any breakpoint; argument ignored.
Continuing.

Breakpoint 1, SetImageBackgroundColor (image=0x63aab0, exception=0x6244d0) at MagickCore/image.c:2464
2464          q+=GetPixelChannels(image);
1: image->columns = 0x40002
2: image->rows = 0x70000
3: x = 0x1bd44
4: y = 0x21d
gdb$ c 100
Will ignore next 255 crossings of breakpoint 1.  Continuing.

Breakpoint 1, SetImageBackgroundColor (image=0x63aab0, exception=0x6244d0) at MagickCore/image.c:2464
2464          q+=GetPixelChannels(image);
1: image->columns = 0x40002
2: image->rows = 0x70000
3: x = 0x1be44
4: y = 0x21d
gdb$ c 1000
Will ignore next 4095 crossings of breakpoint 1.  Continuing.

Breakpoint 1, SetImageBackgroundColor (image=0x63aab0, exception=0x6244d0) at MagickCore/image.c:2464
2464          q+=GetPixelChannels(image);
1: image->columns = 0x40002
2: image->rows = 0x70000
3: x = 0x1ce44
4: y = 0x21d

cin.zip

System Configuration

  • ImageMagick version:7.0.8-26 Q16 x86_64 2019-02-05 (6b3bdb6)
  • Environment (Operating system, version and so on): Ubuntu 18.04 x86_64
  • Additional information: Version 6.9.7-4 Q16 x86_64 20170114 seems fine with error message "width or height exceeds limit `c.cin'".
@dlemstra
Copy link
Member

dlemstra commented Feb 5, 2019

Did you test this with a security policy applied under IM7?

@hongxuchen
Copy link
Author

Oops, I didn't notice the policy.xml setting; this issue and #1473 no longer exist when using the default security policy. I will close them and sorry for the false alarms.

BTW, is there a way to let the command line tools to find the associated configuration xml files when these tools are installed at a customized path (by setting ./configure --prefix=/path/to/installation), as now /path/to/installation/bin/convert -list policy always tells "Undefined" policy?

@hongxuchen
Copy link
Author

@dlemstra I noticed that despite that the policy limit can avoid the issue, this does not fix the root cause: here the cineon image is small enough, however the claimed pixel is huge. I think this can be resolved by checking whether the file size can hold the pixel dimensions and quit immediately when it's not. Similar case for #1473.

@urban-warrior
Copy link
Member

Can you post a link to your c.cin image file? We'll use it as a test case for the patch we think will resolve this problem.

@hongxuchen
Copy link
Author

hongxuchen commented Feb 7, 2019

@urban-warrior c.cin is inside the attached zip file cin.zip (see above).

urban-warrior pushed a commit to ImageMagick/ImageMagick6 that referenced this issue Feb 10, 2019
@urban-warrior
Copy link
Member

Thanks for the problem report. We can reproduce it and will have a patch to fix it in GIT master branch @ https://github.com/ImageMagick/ImageMagick later today. The patch will be available in the beta releases of ImageMagick @ https://www.imagemagick.org/download/beta/ by sometime tomorrow.

@nluedtke
Copy link

This was assigned CVE-2019-11470.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants