Bug 613792 - (CVE-2009-4897) CVE-2009-4897 ghostscript: long name buffer overflow (GS 8.64)
CVE-2009-4897 ghostscript: long name buffer overflow (GS 8.64)
Status: CLOSED NOTABUG
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
high Severity high
: ---
: ---
Assigned To: Red Hat Product Security
public=20090608,reported=20100712,sou...
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-12 16:26 EDT by Vincent Danen
Modified: 2015-08-19 04:50 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-08-18 14:29:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Ghostscript 690523 None None None Never

  None (edit)
Description Vincent Danen 2010-07-12 16:26:06 EDT
A memory corruption vulnerability caused by long names was discovered [1] in Ghostscript 8.64 and earlier.  A specially crafted PDF file could result in the execution of arbitrary code if opened or printed (i.e. via CUPS).

This was corrected in upstream Ghostscript 8.70 [2], version 8.64 and previous are affected by this flaw (all the way back to Ghostscript 7.05).

References:

[1] http://bugs.ghostscript.com/show_bug.cgi?id=690523
[2] http://svn.ghostscript.com/viewvc?view=rev&revision=9797
Comment 2 Tomas Hoger 2010-07-14 11:31:58 EDT
This problem is similar to CVE-2010-1869 (bug #582300) as was noted in oss-security thread:

http://thread.gmane.org/gmane.comp.security.oss.general/3184

(In reply to comment #0)
> This was corrected in upstream Ghostscript 8.70 [2], version 8.64 and previous
> are affected by this flaw (all the way back to Ghostscript 7.05).

The problem that got correct in upstream r9797 goes back to the oldest ghostscript version we currently ship, but does not seem to be an issue in ghostscript versions in Red Hat Enterprise Linux 3, 4, and 5 (7.05 - 8.15.2).

This problem occurs when dynamic_grow() is called with max_size being less than old_size (computed from pda).  Value passed as max_size depends on EXTEND_NAMES
macro value, which specifies parameters of the name table.  Quoting code comment from nameidx.h:

/*
 * The name table machinery has two slightly different configurations:
 * a faster one that limits the total number of names to 64K and allows
 * names up to 16K in size (EXTEND_NAMES == 0), and a slightly slower
 * one that limits the total to 64K << EXTEND_NAMES and and restricts names
 * to 16K >> EXTEND_NAMES. Max value of EXTEND_NAMES is 6, which corresponds
 * to 4M names of up to to 256 characters.
 */

Older ghostscript versions define EXTEND_NAMES to 0, which implies names up to 16k characters are supported.  In 8.64, default value is 4, which increases number of names, but limits their length to 1k.  The default was changed in the following upstream commit:

http://svn.ghostscript.com/viewvc?view=rev&revision=8805

old_size depends on the way ghostscript reads files.  It uses a buffer of 2048 characters, which may cause dynamic_grow() to be called with old_size > max_size.  Such situation does not occur on builds with EXTEND_NAMES 0, and following resizes work correctly.

We may apply the fix in the next ghostscript update to make sure this does not get exposed via some future patch applied to ghostscript packages.
Comment 6 Josh Bressers 2011-08-18 14:29:51 EDT
As this doesn't affect any version of ghostscript we ship, I'm closing this bug.

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