customer service mailbox
22/12/04, 01:35
libtiff STRIPOFFSETS Integer Overflow Vulnerability
iDEFENSE Security Advisory 12.21.04
www.idefense.com/application/poi/display?id=3D173&type=3Dvulnerabilities
December 21, 2004
I. BACKGROUND
libtiff provides support for the Tag Image File Format (TIFF), a widely=20
used format for storing image data.
More information is available at the following site:=20
http://www.remotesensing.org/libtiff/
II. DESCRIPTION
Remote exploitation of an integer overflow in libtiff may allow for the=20
execution of arbitrary code.
The overflow occurs in the parsing of TIFF files set with the=20
STRIPOFFSETS flag in libtiff/tif_dirread.c. In the TIFFFetchStripThing()
function, the number of strips (nstrips) is used directly in a=20
CheckMalloc() routine without sanity checking. The call ultimately boils
down to:
malloc(user_supplied_int*size(int32));
When supplied 0x40000000 as the user supplied integer, malloc is called=20
with a length argument of 0. This has the effect of returning the=20
smallest possible malloc chunk. A user controlled buffer is subsequently
copied to that small heap buffer, causing a heap overflow.
When exploited, it is possible to overwrite heap structures and seize=20
control of execution.
III. ANALYSIS
An attacker can exploit the above-described vulnerability to execute=20
arbitrary code under the permissions of the target user. Successful=20
exploitation requires that the attacker convince the end user to open=20
the malicious TIFF file using an application linked with a vulnerable=20
version of libtiff. Exploitation of this vulnerability against a remote=20
target is difficult because of the precision required in the attack.
IV. DETECTION
iDEFENSE has confirmed this vulnerability in libtiff 3.6.1. Changes were
introduced in libtiff 3.7.0 that had the effect of fixing this=20
vulnerability.
The following vendors provide susceptible libtiff packages within their=20
respective operating system distributions:=20
=09
- Gentoo Linux=20
- Fedora Linux=20
- RedHat Linux=20
- SuSE Linux=20
- Debian Linux=20
V. WORKAROUND
Only open TIFF files from trusted users.
VI. VENDOR RESPONSE
This issue is addressed in libtiff 3.7.0 and 3.7.1.
VII. CVE INFORMATION
A Mitre Corp. Common Vulnerabilities and Exposures (CVE) number has not
been assigned yet.
VIII. DISCLOSURE TIMELINE
12/15/2004 Discovery of fix in later software version
12/21/2004 Public disclosure
IX. CREDIT
infamous41md[at]hotpop.com is credited with this discovery.
Get paid for vulnerability research
http://www.idefense.com/poi/teams/vcp.jsp
X. LEGAL NOTICES
Copyright (c) 2004 iDEFENSE, Inc.
Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDEFENSE. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically, please
email customerservice@idefense.com for permission.
Disclaimer: The information in the advisory is believed to be accurate
at the time of publishing based on currently available information. Use
of the information constitutes acceptance for use in an AS IS condition.
There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct, indirect,
or consequential loss or damage arising from use of, or reliance on,
this information.
iDEFENSE Security Advisory 12.21.04
www.idefense.com/application/poi/display?id=3D173&type=3Dvulnerabilities
December 21, 2004
I. BACKGROUND
libtiff provides support for the Tag Image File Format (TIFF), a widely=20
used format for storing image data.
More information is available at the following site:=20
http://www.remotesensing.org/libtiff/
II. DESCRIPTION
Remote exploitation of an integer overflow in libtiff may allow for the=20
execution of arbitrary code.
The overflow occurs in the parsing of TIFF files set with the=20
STRIPOFFSETS flag in libtiff/tif_dirread.c. In the TIFFFetchStripThing()
function, the number of strips (nstrips) is used directly in a=20
CheckMalloc() routine without sanity checking. The call ultimately boils
down to:
malloc(user_supplied_int*size(int32));
When supplied 0x40000000 as the user supplied integer, malloc is called=20
with a length argument of 0. This has the effect of returning the=20
smallest possible malloc chunk. A user controlled buffer is subsequently
copied to that small heap buffer, causing a heap overflow.
When exploited, it is possible to overwrite heap structures and seize=20
control of execution.
III. ANALYSIS
An attacker can exploit the above-described vulnerability to execute=20
arbitrary code under the permissions of the target user. Successful=20
exploitation requires that the attacker convince the end user to open=20
the malicious TIFF file using an application linked with a vulnerable=20
version of libtiff. Exploitation of this vulnerability against a remote=20
target is difficult because of the precision required in the attack.
IV. DETECTION
iDEFENSE has confirmed this vulnerability in libtiff 3.6.1. Changes were
introduced in libtiff 3.7.0 that had the effect of fixing this=20
vulnerability.
The following vendors provide susceptible libtiff packages within their=20
respective operating system distributions:=20
=09
- Gentoo Linux=20
- Fedora Linux=20
- RedHat Linux=20
- SuSE Linux=20
- Debian Linux=20
V. WORKAROUND
Only open TIFF files from trusted users.
VI. VENDOR RESPONSE
This issue is addressed in libtiff 3.7.0 and 3.7.1.
VII. CVE INFORMATION
A Mitre Corp. Common Vulnerabilities and Exposures (CVE) number has not
been assigned yet.
VIII. DISCLOSURE TIMELINE
12/15/2004 Discovery of fix in later software version
12/21/2004 Public disclosure
IX. CREDIT
infamous41md[at]hotpop.com is credited with this discovery.
Get paid for vulnerability research
http://www.idefense.com/poi/teams/vcp.jsp
X. LEGAL NOTICES
Copyright (c) 2004 iDEFENSE, Inc.
Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDEFENSE. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically, please
email customerservice@idefense.com for permission.
Disclaimer: The information in the advisory is believed to be accurate
at the time of publishing based on currently available information. Use
of the information constitutes acceptance for use in an AS IS condition.
There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct, indirect,
or consequential loss or damage arising from use of, or reliance on,
this information.