Stack smashing in convert, compare

[tapanit]

I'm getting lots of errors like this:

$ convert -rotate 270 003632r270.jpg koe.jpg
*** stack smashing detected ***: convert terminated
Aborted (core dumped)

The bug can also be triggered by compare:

$ compare -fuzz 25% 174210.jpg 182452.jpg junk.jpg
*** stack smashing detected ***: compare terminated
Aborted

This happens with versions 6.7.7 (packaged in Ubuntu 14.04 and 14.10) and 6.7.8 (in OpenSuse 12.3)
as well as in 6.8.9 (built from original source, tested in Ubuntu 14.04 and 12.04),
but not with 6.6.9 (packaged in Ubuntu 12.04) nor with 6.5.4 (in RHEL6).

Sample files used above can be found here:

http://tapani.tarvainen.info/linux/convertbug/

I have lots more if someone needs them.
They're out-of-camera JPEGs that work without issues in all other software I've tried.

There's an Ubuntu bug report open on this, too:
https://bugs.launchpad.net/ubuntu/+sour ... ug/1385903

[magick]

Its likely a bug in the JPEG library:

Code: Select all

convert -rotate 270 003632r270.jpg junk.jpg
*** stack smashing detected ***: convert terminated
======= Backtrace: =========
/lib64/libc.so.6[0x3bb1075a4f]
/lib64/libc.so.6(__fortify_fail+0x37)[0x3bb1106947]
/lib64/libc.so.6(__fortify_fail+0x0)[0x3bb1106910]
/lib64/libjpeg.so.62[0x3bc540ff6c]
/lib64/libjpeg.so.62[0x3bc5404d18]
/lib64/libjpeg.so.62(jpeg_finish_compress+0x96)[0x3bc54045d6]
/usr/local/lib/ImageMagick-6.8.9/modules-Q16/coders/jpeg.so(+0x7bf7)[0x7f8f0d2a6bf7]

The jpeg_finish_compress() method is in the JPEG library. In ImageMagick's coders/jpeg.c/2230 we set the optimize coding member of the JPEG initialization structure to TRUE. If we set it to FALSE, ImageMagick completes without complaint. While the bug is investigated, we'll turn off compression optimization to prevent the stack smash:

• coders/jpeg.c/2230:
  jpeg_info.optimize_coding=FALSE:

[broucaries]

It is thus a security bug on jpeg library. Could you please report and open a ubuntu bug.

Please also test against lastest debian version..if so i will open a bug (i am the debian imagemagick maintainer)

[tapanit]

Curiously, the bug does not seem to be present in Debian Wheezy, even though it has same ImageMagick version as Ubuntu Trusty. Perhaps it was built with different options?

I don't have Sid or Jessie machines at hand, I'll try to find the time to install them to test.

[broucaries]

Likely because libjpeg was not hardened

[broucaries]

BWT it will be nice to compile for regression testing imagemagick with hardening flags

Bastien

[broucaries]

See also on going discussion on http://bugs.debian.org/768369

Magick could you help libjpeg upstream by improving my answer.

Bastien

[magick]

What works:

• convert 003632r270.jpg -rotate 270 junk.jpg

This works too with libjpeg-6b:

• convert -define jpeg:optimize-coding=true 003632r270.jpg -rotate 270 junk.jpg

The same command fails if we use libturbojpeg 1.3.1:

Code: Select all

gdb convert
run -define jpeg:optimize-coding=true 003632r270.jpg -rotate 270 junk.jpg
*** stack smashing detected ***: /usr/local/bin/convert terminated
...
where
#0  0x0000003bb1035877 in raise () from /lib64/libc.so.6
#1  0x0000003bb1036f68 in abort () from /lib64/libc.so.6
#2  0x0000003bb1075a54 in __libc_message () from /lib64/libc.so.6
#3  0x0000003bb1106947 in __fortify_fail () from /lib64/libc.so.6
#4  0x0000003bb1106910 in __stack_chk_fail () from /lib64/libc.so.6
#5  0x00000000007c6b2b in encode_mcu_huff (cinfo=0x7fffffff83b0,
    MCU_data=0xc54110) at jchuff.c:641
#6  0x00000000007b9399 in compress_output (cinfo=0x7fffffff83b0,
    input_buf=<optimized out>) at jccoefct.c:381
#7  0x0000000000795426 in jpeg_finish_compress (
    cinfo=cinfo@entry=0x7fffffff83b0) at jcapimin.c:183
#8  0x00000000005741df in WriteJPEGImage (image_info=0xc4fb40, image=0xc41b10)
    at coders/jpeg.c:2794
#9  0x00000000005de602 in WriteImage (image_info=image_info@entry=0xc06950,
    image=image@entry=0xc41b10) at magick/constitute.c:1114
...

To reproduce:

Code: Select all

wget http://www.imagemagick.org/download/ImageMagick-6.8.9-10.tar.gz
tar xvf ImageMagick-6.8.9-10.tar.gz
cd ImageMagick-6.8.9-10
<download / unpack libjpeg-turbo>
mv libjpeg-turbo-1.3.1 jpeg
cd jpeg
export CFLAGS="-O3 -fPIC -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector"
./configure --disable-shared
make
cd ..
./configure --enable-delegate-build --disable-shared
make -j3
make install
gdb convert
run -define jpeg:optimize-coding=true 003632r270.jpg -rotate 270 junk.jpg
*** stack smashing detected ***: /usr/local/bin/convert terminated

Did ImageMagick corrupt the stack? Possible, we're investigating, however, its curious that the same command works for libjpeg-6b. We did use valgrind and valgrind did not reveal any memory corruption in ImageMagick.

[broucaries]

Di you check if both imagemagick and libjpeg-6b are compiled with -fstack-protector-all ? Valgrind is really bad at detecting stack issue.

Bastien

[magick]

Yes, -fstack-protector-all was set for libjpeg-6b and libturbo as well as ImageMagick.

[dlemstra]

I was able to reproduce the problem under Windows that uses libturbo 1.3.0. It looks like the problem is inside the STORE_BUFFER macro at line 421 of jchuff.c:

Code: Select all

buffer = _buffer; \
while (bytes > 0) { \
  bytestocopy = min(bytes, state->free_in_buffer); \
  MEMCOPY(state->next_output_byte, buffer, bytestocopy); \
  state->next_output_byte += bytestocopy; \
  buffer += bytestocopy; \
  state->free_in_buffer -= bytestocopy; \
  if (state->free_in_buffer == 0) \
    if (! dump_buffer(state)) return FALSE; \
  bytes -= bytestocopy; \
} \

The size of _buffer is BUF_SIZE = (DCTSIZE2 * 2) = (64 * 2) = 128. The following is happening at *block == -591:

1. bytes = 171, state->free_in_buffer = 14 and bytestocopy becomes 14
2. memcopy is called and the buffer is moved to index 14
4. state->free_in_buffer becomes 0, dump_buffer is called and returns true
5. bytes = 157, state->free_in_buffer = 16384 and bytestocopy becomes 157

(14 + 157) > 128 and this causes a buffer overflow.

Not sure why bytes becomes more then 128 but this info should probably give the maintainers of libjpegturbo a bit more information to investigate this issue.

[broucaries]

It is a bug on openjpeg you could revert the workarround. A cve has been assigned and bug was corrected in libjpeg turbo