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.
Name: Scott Gayou (Red Hat)
Unembargoed due to very low impact. Upstream notified.
Created ttembed tracking bugs for this issue:
Affects: fedora-all [bug 1611686]
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);
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.