Bug 995965 (CVE-2013-4231)

Summary: CVE-2013-4231 libtiff (gif2tiff): GIF LZW decoder missing datasize value check
Product: [Other] Security Response Reporter: Murray McAllister <mmcallis>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: erik-fedora, gbarros, jkurik, phracek, vdanen, vkrizan
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: impact=moderate,public=20130801,reported=20130807,source=researcher,cvss2=5.1/AV:N/AC:H/Au:N/C:P/I:P/A:P,fedora-all/libtiff=affected,fedora-all/mingw-libtiff=affected,rhel-6/libtiff=affected,rhel-5/libtiff=affected,rhel-7/libtiff=notaffected
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-02-27 14:29:59 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On: 996827, 996832, 996833, 1063460, 1063461, 1063464, 1063465    
Bug Blocks: 994449    

Description Murray McAllister 2013-08-12 01:15:22 EDT
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 01:41:45 EDT
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 01:51:16 EDT
(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 04:26:29 EDT
(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 01:34:45 EDT
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 01:47:09 EDT
Created libtiff tracking bugs for this issue:

Affects: fedora-all [bug 996832]
Comment 8 Huzaifa S. Sidhpurwala 2013-08-14 01:47:19 EDT
Created mingw-libtiff tracking bugs for this issue:

Affects: fedora-all [bug 996833]
Comment 10 Fedora Update System 2013-08-17 20:31:04 EDT
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-17 20:38:32 EDT
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 11:08:16 EST
(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 13:34:12 EST
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 13:35:36 EST
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 14:29:59 EST
Statement:

(none)