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.
ttembed fails to check the return of fgetc for failures which can lead to output file corruption.
Note the following:
unsignedlongreadbe32(FILE *f)
{
unsignedlong 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.
The security implications of this seem rather unimportant as an attacker submitting a corrupted file and the application further corrupting it seems rather obtuse, but perhaps some consumer downstream of ttembed may rely on correct files being output. Nevertheless, ttembed should still terminate early in this case before writing.
Reproducer attached. Copy modify.ttf to modify.bak, run ttembed on modify.ttf, then diff the file and the bak. They will be different.
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.
ttembed fails to check the return of fgetc for failures which can lead to output file corruption.
Note the following:
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.
The security implications of this seem rather unimportant as an attacker submitting a corrupted file and the application further corrupting it seems rather obtuse, but perhaps some consumer downstream of ttembed may rely on correct files being output. Nevertheless, ttembed should still terminate early in this case before writing.
Reproducer attached. Copy modify.ttf to modify.bak, run ttembed on modify.ttf, then diff the file and the bak. They will be different.
modify.zip
This has been assigned CVE-2018-10921
Thank you!
The text was updated successfully, but these errors were encountered: