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
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.
As this doesn't affect any version of ghostscript we ship, I'm closing this bug.