Bug 672165 (CVE-2010-4653) - CVE-2010-4653 xpdf: integer overflow in CharCodeToUnicode::addMapping
Summary: CVE-2010-4653 xpdf: integer overflow in CharCodeToUnicode::addMapping
Keywords:
Status: NEW
Alias: CVE-2010-4653
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 734819
TreeView+ depends on / blocked
 
Reported: 2011-01-24 09:39 UTC by Tomas Hoger
Modified: 2020-07-24 22:34 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)

Description Tomas Hoger 2011-01-24 09:39:48 UTC
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.

Comment 1 Tomas Hoger 2011-01-24 10:16:11 UTC
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.


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