Bugzilla – Bug 781995
VUL-0: CVE-2012-4447: libtiff: Heap-buffer overflow when processing a TIFF image with PixarLog Compression
Last modified: 2013-11-07 12:55:47 UTC
public, via oss-sec: I had a look at the libtiff-4.0.3 commit logs and found one issue which seems to bring a possibility of heap-based buffer overflow when using a tiff file with PixarLog compression format. More details at: https://bugzilla.redhat.com/show_bug.cgi?id=860198 Though memory overwrite outside the heap-buffer is only a few bytes, one cannot really overwrite possible arbitrary code execution. Can a CVE id be please assigned to the above flaw? Found two other commits which seemed interesting, but i dont think they could cause arbitrary code execution and i dont want to call them security flaws. 1. OOB read crash tif_packbits.c 2. Memory not properly initialised in tif_fax3.c. Again this one was partly fixed in 4.0.2 and completely fixed in 4.0.3 If anyone else wants to investigate these in more details, please be my guest :) Thanks! -- Huzaifa Sidhpurwala / Red Hat Security Response Team
https://bugzilla.redhat.com/attachment.cgi?id=616925
Should I start with update or should I wait for > 1. OOB read crash tif_packbits.c > 2. Memory not properly initialised in tif_fax3.c. Again this one was ?
I think we can wait here. If anything comes round on the list, we keep you updated. (needs CVE anyway)
okay, P4 for now
bugbot adjusting priority
The memory overwrite got CVE-2012-4447
BTW, I think their patch is broken and adds another hole since the '+' can overflow inside malloc. Posted to oss-sec.
Sebastian, do you know what's the progress here?
I mailed my concerns to oss-sec and upstream confirmed, but no further info so far. I could either re-ping them or we can fix the '+' ourselfs.
I tried finding the source code repository, but failed :/ the cvs does only result in connection refused. Do you have the url/link/repo?
Note: A different flaw than 787892 / CVE-2012-4564.
Original report and discussion: http://seclists.org/oss-sec/2012/q3/101
Affects: SLE11-SP{1,2} + SLE10-SP{3,4} + all SLE9.
Created attachment 512200 [details] new patch (proposal) Return 0 on overflow in addition. Should be OK as long as the multiplication is guaranteed to not overflow.
Created attachment 512243 [details] new patch (proposal) Previous patch slightly revised
Patch should work, even if tbuf_size > (INT_MAX - i_stride) is the only check that makes sense in the if(). Since sp->stride is uint16_t, i_stride could never be < 0, and tbuf_size + i_stride is undefined anyway if the result doesnt fit in an int. So, the if() check could be relaxed to "tbuf_size > (INT_MAX - i_stride)" IMHO. We should also fix it for the Encode case, there is a similar alloc.
(In reply to comment #16) > Patch should work, even if > > tbuf_size > (INT_MAX - i_stride) > > is the only check that makes sense in the if(). Since sp->stride > is uint16_t, i_stride could never be < 0, and tbuf_size + i_stride > is undefined anyway if the result doesnt fit in an int. > Oops. Taking a break and re-considering it I see it too now. I will relax the condition. [...] > We should also fix it for the Encode case, there is a similar > alloc. Which function do you have in mind?
Created attachment 514212 [details] new patch 2 (proposal)
Gna. That makes me mad now. I could have seen it myself in the first place. Of course a multiplication of two unsigned operands can obviously not be < 0...
This patch is for PixarLogSetupDecode(), but the same alloc could be fixed in PixarLogSetupEncode().
Created attachment 515082 [details] extended patch -- added hunk for PixarLogSetupEncode() Identical hunk for PixarLogSetupEncode() will work?
needinfo
This one remains to make tiff update prepared.
Ping :-).
yes, I think the patch is correct. Should be CVE-2012-4447
The SWAMPID for this issue is 50693. This issue was rated as moderate. Please submit fixed packages until 2013-01-22. When done, please reassign the bug to security-team@suse.de. Patchinfo will be handled by security team.
9sp3: sr#23375 10sp3: sr#23376 11: sr#23377 openSUSE: mr#147545
This is an autogenerated message for OBS integration: This bug (781995) was mentioned in https://build.opensuse.org/request/show/147919 Evergreen:11.2 / tiff
Update released for: libtiff-devel, libtiff-devel-32bit, libtiff3, libtiff3-32bit, tiff, tiff-debuginfo, tiff-debugsource Products: SLE-SERVER 11-SP1-TERADATA (x86_64)
Update released for: libtiff, tiff Products: SUSE-CORE 9-SP3-TERADATA (x86_64)
Update released for: libtiff, libtiff-32bit, libtiff-64bit, libtiff-devel, libtiff-devel-32bit, libtiff-devel-64bit, libtiff-x86, tiff, tiff-debuginfo Products: SLE-DESKTOP 10-SP4 (i386, x86_64) SLE-SDK 10-SP4 (i386, ia64, ppc, s390x, x86_64) SLE-SERVER 10-SP4 (i386, ia64, ppc, s390x, x86_64)
Update released for: libtiff, libtiff-32bit, libtiff-devel, libtiff-devel-32bit, tiff, tiff-debuginfo Products: SLE-SERVER 10-SP3-TERADATA (x86_64)
Update released for: libtiff-devel, libtiff-devel-32bit, libtiff3, libtiff3-32bit, libtiff3-x86, tiff, tiff-debuginfo, tiff-debugsource Products: SLE-DEBUGINFO 11-SP2 (i386, ia64, ppc64, s390x, x86_64) SLE-DESKTOP 11-SP2 (i386, x86_64) SLE-SDK 11-SP2 (i386, ia64, ppc64, s390x, x86_64) SLE-SERVER 11-SP2 (i386, ia64, ppc64, s390x, x86_64) SLES4VMWARE 11-SP2 (i386, x86_64)
all released
This is an autogenerated message for OBS integration: This bug (781995) was mentioned in https://build.opensuse.org/request/show/176384 Evergreen:11.2 / tiff
Update released for: libtiff, libtiff-32bit, libtiff-devel, libtiff-devel-32bit, tiff, tiff-debuginfo Products: SLE-SERVER 10-SP3-LTSS (i386, s390x, x86_64)