Bugzilla – Bug 82787
VUL-0: CVE-2005-1544: libtiff buffer overflow
Last modified: 2021-09-26 10:46:25 UTC
We received the following report via vendor-sec. The issue is semi public. Patch is said to be in libtiff bugzilla, see below Date: Thu, 5 May 2005 16:36:56 +0100 From: Tavis Ormandy <taviso@gentoo.org> To: vendor-sec@lst.de Cc: dron@remotesensing.org, warmerdam@pobox.com, security@imagemagick.org, security@gentoo.org Subject: Re: [vendor-sec] ImageMagick heap overflow User-Agent: Mutt/1.5.8i X-Spam-Level: On Tue, Apr 26, 2005 at 06:48:18PM +0100, Tavis Ormandy wrote: > decoder: tiff > example: > > H4sIAAAAAAACA/P01GIQYmBgqLiVDCQZgVAQSDEDaQYIRmIzgdiMEDYzVJwDiNmgbBDgQlLP ... On closer examination, this appears to be exploitable. I don't know wether the responsibility for validation lies in libtiff (which calls a supplied function with bad data) or the application for trusting it. At least Xv, imagemagick and The Gimp (which all dump core) appear to trust the arguments passed by libtiff to their tiff_readproc function (a fucntion pointer passed to libtiff), so I'll assume this is a libtiff problem. here's a uuencoded sample: begin 644 foo.tiff.gz M'XL(```````"`^W.,0N"0!@&X+NL**%!H8)J<(R&4XL<W-IR:.@GB)A)21*" M_M;FYL;&Z%./N+\0O(]\?J_RPET0K)C)&*L>$;TY/08MC39K1\F=.O,V:_+_ M@*8O<TU7^B/>83KM)XW!N[^^J73&2IXH>2K[0YH9[S7Y13.7^4VS4/I+);MT MKD_[(^^4IU5\%45ZJC_VLM3L(`N3^!`F:72Q/+$6CN5L;,>SG:UU=#WK7!2Y I;]ME68JT;F9-4]SN"=L!``````````````````#`W_L"''3M\C@A```` ` end This issue has been discussed on our publically accessible irc channel, but no announcement has been made yet. -- ------------------------------------- taviso@sdf.lonestar.org | finger me for my gpg key. ------------------------------------------------------- _______________________________________________ Vendor Security mailing list Vendor Security@lst.de https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec Date: Thu, 5 May 2005 19:44:13 +0400 From: "Dmitry V. Levin" <ldv@altlinux.org> To: Tavis Ormandy <taviso@gentoo.org> Cc: vendor-sec@lst.de, Andrey Kiselev <dron@remotesensing.org>, warmerdam@pobox.com, security@imagemagick.org, security@gentoo.org Subject: Re: [vendor-sec] ImageMagick heap overflow X-Spam-Level: * On Thu, May 05, 2005 at 04:36:56PM +0100, Tavis Ormandy wrote: > On Tue, Apr 26, 2005 at 06:48:18PM +0100, Tavis Ormandy wrote: [...] > here's a uuencoded sample: > > begin 644 foo.tiff.gz > M'XL(```````"`^W.,0N"0!@&X+NL**%!H8)J<(R&4XL<W-IR:.@GB)A)21*" > M_M;FYL;&Z%./N+\0O(]\?J_RPET0K)C)&*L>$;TY/08MC39K1\F=.O,V:_+_ > M@*8O<TU7^B/>83KM)XW!N[^^J73&2IXH>2K[0YH9[S7Y13.7^4VS4/I+);MT > MKD_[(^^4IU5\%45ZJC_VLM3L(`N3^!`F:72Q/+$6CN5L;,>SG:UU=#WK7!2Y > I;]ME68JT;F9-4]SN"=L!``````````````````#`W_L"''3M\C@A```` > ` > end This is definitely a libtiff problem: $ tiffinfo foo.tiff foo.tiff: Warning, incorrect count for field "BitsPerSample" (257, expecting 1); tag trimmed. Segmentation fault -- ldv Date: Thu, 5 May 2005 11:47:09 -0400 From: Frank Warmerdam <fwarmerdam@gmail.com> To: Tavis Ormandy <taviso@gentoo.org> Cc: vendor-sec@lst.de, dron@remotesensing.org, security@imagemagick.org, security@gentoo.org Subject: Re: [vendor-sec] ImageMagick heap overflow Reply-To: warmerdam@pobox.com X-Spam-Level: On 5/5/05, Tavis Ormandy <taviso@gentoo.org> wrote: > On Tue, Apr 26, 2005 at 06:48:18PM +0100, Tavis Ormandy wrote: > > > decoder: tiff > > example: > > > > H4sIAAAAAAACA/P01GIQYmBgqLiVDCQZgVAQSDEDaQYIRmIzgdiMEDYzVJwDiNmgbBDgQlLP > ... > > On closer examination, this appears to be exploitable. I don't know > wether the responsibility for validation lies in libtiff (which calls a > supplied function with bad data) or the application for trusting it. > > At least Xv, imagemagick and The Gimp (which all dump core) appear to trust > the arguments passed by libtiff to their tiff_readproc function (a > fucntion pointer passed to libtiff), so I'll assume this is a libtiff problem. > > here's a uuencoded sample: > > begin 644 foo.tiff.gz > M'XL(```````"`^W.,0N"0!@&X+NL**%!H8)J<(R&4XL<W-IR:.@GB)A)21*" > M_M;FYL;&Z%./N+\0O(]\?J_RPET0K)C)&*L>$;TY/08MC39K1\F=.O,V:_+_ > M@*8O<TU7^B/>83KM)XW!N[^^J73&2IXH>2K[0YH9[S7Y13.7^4VS4/I+);MT > MKD_[(^^4IU5\%45ZJC_VLM3L(`N3^!`F:72Q/+$6CN5L;,>SG:UU=#WK7!2Y > I;]ME68JT;F9-4]SN"=L!``````````````````#`W_L"''3M\C@A```` > ` > end Folks, I have submitted it into the libtiff Bugzilla as: http://bugzilla.remotesensing.org/show_bug.cgi?id=843 I didn't raise the question of this being a security risk, just that it causes a crash. I have reproduced the crash but I haven't yet dug into it. I'll take a look today. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent _______________________________________________ Vendor Security mailing list Vendor Security@lst.de https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec Date: Thu, 5 May 2005 20:15:35 +0400 From: "Dmitry V. Levin" <ldv@altlinux.org> To: Frank Warmerdam <warmerdam@pobox.com> Cc: Tavis Ormandy <taviso@gentoo.org>, vendor-sec@lst.de, Andrey Kiselev <dron@remotesensing.org>, security@imagemagick.org, security@gentoo.org Subject: Re: [vendor-sec] libtiff heap overflow X-Spam-Level: * Hi, On Thu, May 05, 2005 at 11:47:09AM -0400, Frank Warmerdam wrote: [...] > I have submitted it into the libtiff Bugzilla as: > > http://bugzilla.remotesensing.org/show_bug.cgi?id=843 Ok, I've attached proposed fix to this bugzilla item. -- ldv Date: Thu, 5 May 2005 14:14:43 -0400 From: Frank Warmerdam <fwarmerdam@gmail.com> To: Tavis Ormandy <taviso@gentoo.org> Cc: vendor-sec@lst.de, dron@remotesensing.org, security@imagemagick.org, security@gentoo.org Subject: Re: [vendor-sec] ImageMagick heap overflow Reply-To: warmerdam@pobox.com X-Spam-Level: Folks, I just wanted to follow up by saying I have applied a patch for this problem in the libtiff CVS. The problem is definately a stack smashing security risk. An appropriately crafted TIFF file will overrun the stack with an arbitrary amount of data on a TIFFOpen() call. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent _______________________________________________ Vendor Security mailing list Vendor Security@lst.de https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec Date: Thu, 5 May 2005 21:50:41 +0100 From: Tavis Ormandy <taviso@gentoo.org> To: vendor-sec@lst.de Subject: Re: [vendor-sec] ImageMagick heap overflow User-Agent: Mutt/1.5.8i X-Spam-Level: On Thu, May 05, 2005 at 04:36:56PM +0100, Tavis Ormandy wrote: > On closer examination, this appears to be exploitable. We are planning to release an update for libtiff around Tuesday next week (10th), if anyone would prefer us to wait please let us know how much time you require. -- ------------------------------------- taviso@sdf.lonestar.org | finger me for my gpg key. ------------------------------------------------------- _______________________________________________ Vendor Security mailing list Vendor Security@lst.de https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
In the libtiff bugzilla, http://bugzilla.remotesensing.org/show_bug.cgi?id=843 there is still a discussion whether the fix is correct. I will make the fixed packages on Monday. Is it OK?
Created attachment 36586 [details] current patch from CVS
fixed packages for sles8, sles9 and 8.2 - 9.3 are submitted.
SM-Tracker-1140
released yesterday...
CAN-2005-1544
CVE-2005-1544: CVSS v2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)