Bug 82787 (CVE-2005-1544)

Summary: VUL-0: CVE-2005-1544: libtiff buffer overflow
Product: [Novell Products] SUSE Security Incidents Reporter: Ludwig Nussel <lnussel>
Component: IncidentsAssignee: Security Team bot <security-team>
Status: RESOLVED FIXED QA Contact: Security Team bot <security-team>
Severity: Normal    
Priority: P5 - None CC: nadvornik, security-team
Version: unspecified   
Target Milestone: ---   
Hardware: Other   
OS: All   
Whiteboard: CVE-2005-1544: CVSS v2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)
Found By: Other Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: current patch from CVS

Description Ludwig Nussel 2005-05-06 13:31:22 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
Comment 1 Vladimir Nadvornik 2005-05-06 14:06:04 UTC
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?
Comment 2 Vladimir Nadvornik 2005-05-09 09:45:03 UTC
Created attachment 36586 [details]
current patch from CVS
Comment 3 Vladimir Nadvornik 2005-05-09 13:09:01 UTC
fixed packages for sles8, sles9 and 8.2 - 9.3 are submitted.
Comment 4 Ludwig Nussel 2005-05-09 13:42:20 UTC
SM-Tracker-1140 
Comment 5 Thomas Biege 2005-05-24 16:05:52 UTC
released yesterday...
Comment 6 Ludwig Nussel 2005-07-14 07:01:57 UTC
CAN-2005-1544 
Comment 7 Thomas Biege 2009-10-13 21:21:47 UTC
CVE-2005-1544: CVSS v2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)