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: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | unspecified | CC: | erik-fedora, gbarros, jkurik, phracek, vdanen, vkrizan |
Target Milestone: | --- | Keywords: | Security |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-02-27 19:29:59 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 996827, 996832, 996833, 1063460, 1063461, 1063464, 1063465 | ||
Bug Blocks: | 994449 |
Description
Murray McAllister
2013-08-12 05:15:22 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. (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. (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 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) Created libtiff tracking bugs for this issue: Affects: fedora-all [bug 996832] Created mingw-libtiff tracking bugs for this issue: Affects: fedora-all [bug 996833] 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. 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. (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. 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 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 Statement: (none) |