Red Hat Bugzilla – Bug 672165
CVE-2010-4653 xpdf: integer overflow in CharCodeToUnicode::addMapping
Last modified: 2018-06-21 05:10:15 EDT
Dan Rosenberg reported an issue in xpdf/poppler code base: http://thread.gmane.org/gmane.comp.security.oss.general/4109 Due to an integer overflow when parsing CharCodes for fonts and a failure to check the return value of a memory allocation, it is possible to trigger writes to a narrow range of offsets from a NULL pointer. The chance of being able to exploit this for anything other than a crash is very remote: on x86 32-bit, there's no chance (since the write occurs between 0xffffffc4 and 0xfffffffc). At least the write lands in valid userspace on x86-64, but in my testing this memory is never mapped. poppler git commit that addresses integer overflow issue: http://cgit.freedesktop.org/poppler/poppler/commit/?id=cad66a7d25abdb6aa15f3aa94a35737b119b2659 Acknowledgements: Red Hat would like to thank Dan Rosenberg for reporting this issue.
Affected code can be reached via GfxFont::readToUnicodeCMap function, which is called both from Gfx8BitFont and GfxCIDFont with different nBits values (8 and 16 respectively). This further calls CharCodeToUnicode::parseCMap1, which reads character codes from the file. Expected character code format is either "<XX>" or "<XXXX>" depending on the nBits value, where X is hexadecimal number. The code value is read using sscanf("%x"), so '-' character is recognized too. parseCMap1 code ensures there are exactly 2 or 4 digits. Reproducer triggering this flaw used char code as "<-1>". This negative value is stored in the unsigned int code variable as high positive value that wraps to 0 when the following computation is performed in addMapping: mapLen = (code + 256) & ~255; Subsequent greallocn call returns NULL as requested nObjs == 0. Unchecked return value cause addMapping to perform a NULL pointer deference. For 8 bit codes, this results in an access to limited address range mentioned in the Dan's report (as code triggering the issue are in the range "<-1>" .. "<-f>"). For nBits == 16, problematic codes are "<-001>" .. "<-fff>". Only the code "<-001>" .. "<-0ff>" trigger integer overflow. Remaining values do not pass an integer overflow check in greallocn, which results in the program abort. Referenced poppler fix does not change the code to handle this error condition more gracefully.