Bug 672165 (CVE-2010-4653)

Summary:	CVE-2010-4653 xpdf: integer overflow in CharCodeToUnicode::addMapping
Product:	[Other] Security Response	Reporter:	Tomas Hoger <thoger>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	mkasik, rdieter, than
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-10-19 21:47:09 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	734819

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.