Bug 995965 (CVE-2013-4231) - CVE-2013-4231 libtiff (gif2tiff): GIF LZW decoder missing datasize value check
Summary: CVE-2013-4231 libtiff (gif2tiff): GIF LZW decoder missing datasize value check
Status: CLOSED ERRATA
Alias: CVE-2013-4231
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=moderate,public=20130801,repor...
Keywords: Security
Depends On: 996827 996832 996833 1063460 1063461 1063464 1063465
Blocks: 994449
TreeView+ depends on / blocked
 
Reported: 2013-08-12 05:15 UTC by Murray McAllister
Modified: 2018-12-04 15:42 UTC (History)
6 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2014-02-27 19:29:59 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2014:0222 normal SHIPPED_LIVE Moderate: libtiff security update 2014-02-27 23:33:36 UTC
Red Hat Product Errata RHSA-2014:0223 normal SHIPPED_LIVE Moderate: libtiff security update 2014-02-27 23:33:30 UTC

Description Murray McAllister 2013-08-12 05:15:22 UTC
Pedro Ribeiro discovered a buffer overflow flaw in rgb2ycbcr, a tool to convert RGB color, greyscale, or bi-level TIFF images to YCbCr images, and multiple buffer overflow flaws in gif2tiff, a tool to convert GIF images to TIFF. A remote attacker could provide a specially-crafted TIFF or GIF file that, when processed by rgb2ycbcr and gif2tiff respectively, would cause the tool to crash or, potentially, execute arbitrary code with the privileges of the user running the tool.

References:

http://www.asmail.be/msg0055359936.html
http://www.openwall.com/lists/oss-security/2013/08/08/6

Comment 2 Huzaifa S. Sidhpurwala 2013-08-13 05:41:45 UTC
Analysis:

This flaw bug consists of 4 buffer-overflow flaws:
(more details at http://www.asmail.be/msg0055359936.html)

Issue #1:

> File: tiff-4.0.3/tools/gif2tiff.c
> Line: 316
> Code snippet:
> void
> readextension(void)
> {
>    int count;
>    char buf[255];

>    (void) getc(infile);
>    while ((count = getc(infile)))
>        fread(buf, 1, count, infile);
>}
>Justification:
> buffer is 256 bytes, but uses getc to get user input. Easy to exploit.

This really seems to be a non-issue. "count = getc(infile)" causes 1 byte to be read from the stream. getc() man pages suggest that "returns it as an unsigned char cast to an int, or EOF on end of file or error". So the output is really just 1 byte, but its cast to an int. (The int cast was chosen by glibc so that you can distinguish between EOF and the character with the same value as EOF)

So the max value of count = 255 bytes which are subsequently read into the 255 byte buffer. So no overflow here.

Issue #2:

> File: tiff-4.0.3/tools/gif2tiff.c
> Line: 343-344
> Code snippet:
>    unsigned char buf[255];
>    register int bits=0;
>    register unsigned long datum=0;
>    register unsigned char *ch;
>    register int count, code;
>    int status = 1;

>    datasize = getc(infile);
>    clear = 1 << datasize;
>    eoi = clear + 1;
>    avail = clear + 2;
>    oldcode = -1;
>    codesize = datasize + 1;
>    codemask = (1 << codesize) - 1;
>    for (code = 0; code < clear; code++) {
> prefix[code] = 0;
> suffix[code] = code;
> Justification:
> buf is 255 but datasize is read from file input. If a crafted file provides
> a datasize of 22, clear will be 4194304 (1 << 22). This means that a big
> chunk of memory will become corrupted.

This seems to be a real issue.
Upstream bug: http://bugzilla.maptools.org/show_bug.cgi?id=2450
Proposed patch: http://bugzilla.maptools.org/attachment.cgi?id=514&action=diff

Issue #3:

> File: tiff-4.0.3/tools/gif2tiff.c
> Line: 348
> Code snippet:
>     for (count = getc(infile); count > 0; count = getc(infile)) {
> fread(buf,1,count,infile);
> Justification:
> buf is 255 but function reads count and input from user. Easy to exploit.

Again a non-issue, explanation similar to Issue #1

Issue #4:

> File: tiff-4.0.3/tools/rgb2ycbcr.c
> Line: 335
> Code snippet:
> { char buf[2048];
>  char *cp = strrchr(TIFFFileName(in), '/');
>  sprintf(buf, "YCbCr conversion of %s", cp ? cp+1 : TIFFFileName(in));
>  TIFFSetField(out, TIFFTAG_IMAGEDESCRIPTION, buf);
> }
> Justification:
> Use of sprintf to write into a 2048 character buffer. The input is the
> filename, which might be over 2048 if crafted by a malicious user. However
> I could not determine this as the code is not easy to navigate.

This issue is already fixed in upstream libtiff, when CVE-2013-1961 was addressed.

Upstream commit:
revision 1.15
date: 2013-05-02 14:44:29 +0000;  author: tgl;  state: Exp;  lines: +3 -2;  commitid: YuS5m45QzTCN94Ow;
Replace sprintf with snprintf, to fix CVE-2013-1961.

Comment 3 Tomas Hoger 2013-08-13 05:51:16 UTC
(In reply to Huzaifa S. Sidhpurwala from comment #2)

> Issue #2:

> Proposed patch:
> http://bugzilla.maptools.org/attachment.cgi?id=514&action=diff

Proposed patch does not seem correct.  The check should be done for datasize, not clear.

Comment 4 Huzaifa S. Sidhpurwala 2013-08-13 08:26:29 UTC
(In reply to Tomas Hoger from comment #3)
> (In reply to Huzaifa S. Sidhpurwala from comment #2)
> 
> > Issue #2:
> 
> > Proposed patch:
> > http://bugzilla.maptools.org/attachment.cgi?id=514&action=diff
> 
> Proposed patch does not seem correct.  The check should be done for
> datasize, not clear.

New patch at:

http://bugzilla.maptools.org/attachment.cgi?id=515&action=diff

Comment 6 Huzaifa S. Sidhpurwala 2013-08-14 05:34:45 UTC
This issue has been addressed upstream via the following cvs commit:

revision 1.13
date: 2013-08-14 05:18:53 +0000;  author: fwarmerdam;  state: Exp;  lines: +3 -1;  commitid: xSCHWOlmQbivGn1x;
make more resistent to corrupt/hostile input files (#2450, CVE-2013-4231)

Comment 7 Huzaifa S. Sidhpurwala 2013-08-14 05:47:09 UTC
Created libtiff tracking bugs for this issue:

Affects: fedora-all [bug 996832]

Comment 8 Huzaifa S. Sidhpurwala 2013-08-14 05:47:19 UTC
Created mingw-libtiff tracking bugs for this issue:

Affects: fedora-all [bug 996833]

Comment 10 Fedora Update System 2013-08-18 00:31:04 UTC
libtiff-4.0.3-8.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 11 Fedora Update System 2013-08-18 00:38:32 UTC
libtiff-4.0.3-8.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 14 Tomas Hoger 2014-02-11 16:08:16 UTC
(In reply to Huzaifa S. Sidhpurwala from comment #2)
> This flaw bug consists of 4 buffer-overflow flaws:
> (more details at http://www.asmail.be/msg0055359936.html)

There were 5 issues in the report:


1) Unchecked getc() return value leading to overflow

Issue: Buffer overflow
Impact:Critical
Exploitability:Easy
File: tiff-4.0.3/tools/gif2tiff.c
Line: 316

This was invalid report.


2) Missing datasize value check in GIF LZW decoder leading to overlow

Issue: Buffer overflow (memory corruption)
Impact:Critical
Exploitability:Medium
File: tiff-4.0.3/tools/gif2tiff.c
Line: 343-344

This got CVE-2013-4231 and is tracked by this bug.


3) Unchecked getc() return value leading to overflow

Issue: Buffer overflow
Impact:Critical
Exploitability:Easy
File: tiff-4.0.3/tools/gif2tiff.c
Line: 348

Similar to 1), invalid report.


4) Use-after-free in t2p_readwrite_pdf_image()

Issue: Use after free
Impact:High
Exploitability:Undetermined
File: tiff-4.0.3/tools/tiff2pdf.c
Line: 2469

This got CVE-2013-4232 and is tracked via separate bug 995975.


5) sprintf buffer overflow

Issue: Buffer overflow
Impact:High
Exploitability:Undetermined
File: tiff-4.0.3/tools/rgb2ycbcr.c
Line: 335

Not really security issue, as overflow is triggered by an input file name provided as tool's command line argument, which is usually trusted input.  As pointed out in comment 2, this was already addressed with other sprintf uses via CVE-2013-1961 tracked via bug 952131.

Comment 15 errata-xmlrpc 2014-02-27 18:34:12 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2014:0223 https://rhn.redhat.com/errata/RHSA-2014-0223.html

Comment 16 errata-xmlrpc 2014-02-27 18:35:36 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2014:0222 https://rhn.redhat.com/errata/RHSA-2014-0222.html

Comment 17 Vincent Danen 2014-02-27 19:29:59 UTC
Statement:

(none)


Note You need to log in before you can comment on or make changes to this bug.