Bugzilla – Bug 753362
VUL-0: CVE-2012-1173: libtiff heap based buffer overflow in TIFFReadRGBAImageOriented
Last modified: 2018-10-19 18:08:27 UTC
Your friendly security team received the following report via vendor-sec. Please respond ASAP. This issue is not public yet, please keep any information about it inside SUSE. Note that build.opensuse.org *cannot* be used to prepare embargoed updates. ZDI reports an integer overflow in libtiff's TIFFReadRGBAImageOriented that leads to a heap-based buffer overflow
bugbot adjusting priority
libtiff 3.9.6, 4.0.1 and older are affected. Tom Lane of RedHat prepared patches.
Created attachment 484405 [details] libtiff4-cve-2012-1173.patch
Created attachment 484407 [details] libtiff39-cve-2012-1173.patch
The SWAMPID for this issue is 46537. This issue was rated as moderate. Please submit fixed packages until 2012-04-16. When done, please reassign the bug to security-team@suse.de. Patchinfo will be handled by security team.
I have packages prepared for all distributions, so I can submit them immediately, but ... How can I trigger this heap overflow? $ tiffinfo poc.tif poc.tif: Integer overflow in TIFFVTileSize. TIFFReadDirectory: poc.tif: cannot handle zero tile size. ------ That's because of multiply() buffer overflow check: Breakpoint 1, multiply (nmemb=18446744071562067968, elem_size=1, where=0x7ffff7bd1962 "TIFFVTileSize", tif=<optimized out>) at tif_tile.c:54 54 uint32 bytes = nmemb * elem_size; (gdb) c Continuing. poc.tif: Integer overflow in TIFFVTileSize. Program exits immediately after this check with TIFFReadDirectory: poc.tif: cannot handle zero tile size. because bytes is set to 0 when this check in multiply() failed. Program doesn't reach patched gtTileSeparate() and gtStripSeparate() at all.
No needinfo intended (so far).
is the check that prevents the poc from working from upstream or introduced by a previous patch?
It seems, that poc is not working for me. Look (gdb session on i586, tiff 4.0.1 from graphics repository): Breakpoint 13, _TIFFVSetField (tif=0x804d4f8, tag=322, ap=0xffffda1c "") at tif_dir.c:326 326 td->td_tilewidth = v32; (gdb) c Continuing. Breakpoint 11, TIFFReadDirectory (tif=0x804d4f8) at tif_dirread.c:4062 4062 tif->tif_tilesize = TIFFTileSize(tif); (gdb) s TIFFTileSize (tif=0x804d4f8) at tif_tile.c:254 254 m=TIFFTileSize64(tif); (gdb) n 255 n=(tmsize_t)m; (gdb) n 256 if ((uint64)n!=m) (gdb) p n $22 = -2147483648 (gdb) p m $23 = 2147483648 (gdb) (gdb) whatis m type = uint64 (gdb) whatis n type = tmsize_t (gdb) whatis tmsize_t type = long int td_tilewidth = 8388608, td_tilelength = 256 => m = td_tilewidh * td_tilelength = -2147483648 So, for this tilewidth and tilelength the check in TIFFTileSize() fails and TIFFTileSize() returns 0. Nevertheless, running program again, but lowering tilewidh by one: Breakpoint 13, _TIFFVSetField (tif=0x804d4f8, tag=322, ap=0xffffda1c "") at tif_dir.c:326 326 td->td_tilewidth = v32; (gdb) set v32=v32-1 (gdb) p v32 $16 = 8388607 (gdb) c Continuing. Breakpoint 11, TIFFReadDirectory (tif=0x804d4f8) at tif_dirread.c:4062 4062 tif->tif_tilesize = TIFFTileSize(tif); (gdb) s TIFFTileSize (tif=0x804d4f8) at tif_tile.c:254 254 m=TIFFTileSize64(tif); (gdb) n 255 n=(tmsize_t)m; (gdb) n 256 if ((uint64)n!=m) (gdb) p m $17 = 2147483392 (gdb) p n $18 = 2147483392 (gdb) c Continuing. Breakpoint 7, gtTileSeparate (img=0xffffd76c, raster=0xf7a6d008, w=800, h=607) at tif_getimage.c:684 684 TIFF* tif = img->tif; (gdb) n 685 tileSeparateRoutine put = img->put.separate; (gdb) n 696 int alpha = img->alpha; (gdb) n 698 int ret = 1, flip; (gdb) n 701 tilesize = TIFFTileSize(tif); (gdb) n 702 buf = (unsigned char*) _TIFFmalloc((alpha?4:3)*tilesize); (gdb) p tilesize $19 = 2147483392 (gdb) p 4*tilesize $20 = -1024 (gdb) So I guess the fix is really needed, nevertheless I am not able to create poc which would work for me. I'll check the same for 10sp4 later today, and when I get same result, I will submit packages with this fix. Do you agree?
ok
9sp4: 18454 10sp4: 18455 11sp1: 18456 opensuse tomorrow
CVE-2012-1173
Done, see sr#112474. I am using my new shiny checkouting script intended to work with new maintenance workflow, if goes something wrong please tell me, thanks.
Update released for: libtiff, tiff Products: SUSE-CORE 9-SP3-TERADATA (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-SP1 (i386, ia64, ppc64, s390x, x86_64) SLE-DESKTOP 11-SP1 (i386, x86_64) SLE-DESKTOP 11-SP1-FOR-SP2 (i386, x86_64) SLE-SDK 11-SP1 (i386, ia64, ppc64, s390x, x86_64) SLE-SDK 11-SP1-FOR-SP2 (i386, ia64, ppc64, s390x, x86_64) SLE-SERVER 11-SP1 (i386, ia64, ppc64, s390x, x86_64) SLE-SERVER 11-SP1-FOR-SP2 (i386, ia64, ppc64, s390x, x86_64) SLE-SERVER 11-SP1-TERADATA (x86_64) SLES4VMWARE 11-SP1 (i386, 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)
seems done
openSUSE-SU-2012:0539-1: An update that fixes one vulnerability is now available. Category: security (moderate) Bug References: 753362 CVE References: CVE-2012-1173 Sources used: openSUSE 12.1 (src): tiff-3.9.5-8.4.1 openSUSE 11.4 (src): tiff-3.9.4-3.25.1
This is an autogenerated message for OBS integration: This bug (753362) was mentioned in https://build.opensuse.org/request/show/115050 Evergreen:11.2 / tiff
This is an autogenerated message for OBS integration: This bug (753362) was mentioned in https://build.opensuse.org/request/show/115291 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)