Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 1610539 - (CVE-2018-10921) CVE-2018-10921 ttembed: failure to check file bounds may lead to input file corruption
CVE-2018-10921 ttembed: failure to check file bounds may lead to input file c...
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20180802:1545,repor...
: Security
Depends On: 1611684 1611685 1611686
Blocks: 1608880 1610916
  Show dependency treegraph
 
Reported: 2018-07-31 17:17 EDT by Scott Gayou
Modified: 2018-08-02 12:26 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Certain input files may trigger an integer overflow in ttembed input file processing. This overflow could potentially lead to corruption of the input file due to a lack of checking return codes of fgetc/fputc function calls.
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Scott Gayou 2018-07-31 17:17:17 EDT
ttembed fails to validate file bounds before reading and seeking in the input file. This can lead to an integer overflow and the corruption of the input file.
Comment 1 Scott Gayou 2018-07-31 17:18:41 EDT
Acknowledgments:

Name: Scott Gayou (Red Hat)
Comment 4 Scott Gayou 2018-08-02 11:45:15 EDT
Unembargoed due to very low impact. Upstream notified.
Comment 5 Scott Gayou 2018-08-02 11:48:56 EDT
Created ttembed tracking bugs for this issue:

Affects: fedora-all [bug 1611686]
Comment 7 Scott Gayou 2018-08-02 12:15:06 EDT
Upstream Issue:

https://github.com/hisdeedsaredust/ttembed/issues/3
Comment 8 Scott Gayou 2018-08-02 12:26:46 EDT
Note the following:

unsigned long readbe32(FILE *f)
{
    unsigned long v;
    v  = fgetc(f) << 24;
    v |= fgetc(f) << 16;
    v |= fgetc(f) << 8;
    v |= fgetc(f);
    return v;
}

readbe32 should be checking for EOF. The application fails to verify that reads will succeed via ensuring minimum file-lengths.
Instead, it blindly reads and fails to check that EOF is not returned. As such, large negative values are returned by readbe32.

One obvious case occurs on line 49 where fstype is set to the output of readbe32. If no more bytes can be read from the file handle,
readbe32 will return -1. A fseek on line 51 adds 8 to -1, which wraps around to an fseek of 7, which is valid. This later leads to incorrect writes and "corruption" of the input file.

All usages of fgetc should be checked else file bounds should be verified before fseeks/fgetcs are called.

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