libjpeg-turbo Stack smashing

2014.11.07
Risk: High
Local: Yes
Remote: No
CVE: N/A
CWE: N/A

A-ha, I was able to repro with ImageMagick + libjpeg-turbo 1.2.1. Versions of libjpeg-turbo prior to 1.3.1 accept the file, while 1.3.1 rejects it outright due to duplicate SOI markers. This is probably attributable to this change: [4] Fixed a couple of issues whereby malformed JPEG images would cause libjpeg-turbo to use uninitialized memory during decompression. ...which I think is related to CVE-2013-6629 and CVE-2013-6630. But I haven't spent much time on it, so I'm not sure if that actually fixed the underlying issue, or just made the file invalid for some unrelated reason. The fault is in: ... #6 0x0066e504 in __stack_chk_fail_local () from /usr/lib/libjpeg.so.62 #7 0x0063f9c7 in encode_mcu_huff (cinfo=0xbfffbbf0, MCU_data=0xb49043f8) at jchuff.c:642 <- boop #8 0x0063323f in compress_output (cinfo=0xbfffbbf0, input_buf=0x0) at jccoefct.c:381 #9 0x00632b37 in jpeg_finish_compress (cinfo=0xbfffbbf0) at jcapimin.c:183 #10 0x08319773 in WriteJPEGImage () #11 0x0839c8aa in WriteImage () #12 0x0839d5f3 in WriteImages () FWIW, Debian bug is here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768369 Which points to: http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=26482&sid=81658bc2f51a8d9893279cd01e83783f The test case is at: http://tapani.tarvainen.info/linux/convertbug/r270/003632r270.jpg

References:

http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=26482&sid=81658bc2f51a8d9893279cd01e83783f
http://tapani.tarvainen.info/linux/convertbug/r270/003632r270.jpg
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768369


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2019, cxsecurity.com

 

Back to Top