Bug 690523

Summary:	gs pdf parsing buffer overflow
Product:	Ghostscript	Reporter:	knud <kokanin>
Component:	PDF Interpreter	Assignee:	Alex Cherepanov <alex>
Status:	RESOLVED FIXED
Severity:	normal	CC:	alex, jackie.rosen
Priority:	P4	Keywords:	bountiable
Version:	0.00
Hardware:	PC
OS:	All
Customer:		Word Size:	---

Description knud 2009-06-08 09:51:48 UTC

ghostscript 8.63 pdf parsing overflow 

sample malformed file:
Program terminated with signal 11, Segmentation fault.
[New process 22489]
#0  0xb7860dde in gs_gc_reclaim () from /usr/lib/libgs.so.8
(gdb) i r
eax            0x41414141       1094795585
ecx            0x8195374        135877492
edx            0x81779a8        135756200
ebx            0xb7c7cff4       -1211641868
esp            0xbfd4fb30       0xbfd4fb30
ebp            0xbfd50278       0xbfd50278
esi            0x8193b28        135871272
edi            0x43434343       1128481603
eip            0xb7860dde       0xb7860dde <gs_gc_reclaim+494>
eflags         0x210287 [ CF PF SF IF RF ID ]
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0
gs             0x33     51
(gdb) x/11i $pc
0xb7860dde <gs_gc_reclaim+494>: mov    0xc(%eax),%edx
0xb7860de1 <gs_gc_reclaim+497>: orl    $0xfffffffe,(%esi)
0xb7860de4 <gs_gc_reclaim+500>: test   %edx,%edx
0xb7860de6 <gs_gc_reclaim+502>: je     0xb7860e02 <gs_gc_reclaim+530>
0xb7860de8 <gs_gc_reclaim+504>: mov    %eax,0xc(%esp)
0xb7860dec <gs_gc_reclaim+508>: lea    0xc(%esi),%eax
0xb7860def <gs_gc_reclaim+511>: mov    %eax,0x4(%esp)
0xb7860df3 <gs_gc_reclaim+515>: mov    -0x6c8(%ebp),%eax
0xb7860df9 <gs_gc_reclaim+521>: mov    %edi,0x8(%esp)
0xb7860dfd <gs_gc_reclaim+525>: mov    %eax,(%esp)
0xb7860e00 <gs_gc_reclaim+528>: call   *%edx
(gdb) x/x 0x8193b28
0x8193b28:      0x42424242
(gdb) 

analysis shows exploitation is straight forward, since we control eax 
which gets moved to edx which in turn gets called at gs_gc_reclaim+528

bash$ perl pdf2pspoc.pl ; pdf2ps evil.pdf
   **** Warning:  Specified xref location is beyond end of file.
   **** Warning:  An error occurred while reading an XREF table.
   **** The file has been damaged.  This may have been caused
   **** by a problem while converting or transfering the file.
   **** Ghostscript will attempt to recover the data.
   **** Error reading a content stream. The page may be incomplete.
   **** Unknown operator: '%%EOF'
Error: /typecheck in --run--
Operand stack:
   --nostringval--   --dict:5/14(L)--   F1   20   83   7   0   --
nostringval--   Type   Font   Encoding   WinAnsiEncoding   Subtype   14   Type1
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --
nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --
nostringval--   false   1   %stopped_push   1905   1   3   %oparray_pop   
1904   1   3   %oparray_pop   1888   1   3   %oparray_pop   --nostringval--   --
nostringval--   2   1   1   --nostringval--   %for_pos_int_continue   --
nostringval--   --nostringval--   --nostringval--   --nostringval--   
%array_continue   --nostringval--   false   1   %stopped_push   --
nostringval--   %loop_continue   --nostringval--   --nostringval--   --
nostringval--   --nostringval--   false   1   %stopped_push   --nostringval--   
%loop_continue   --nostringval--
Dictionary stack:
   --dict:1150/1684(ro)(G)--   --dict:1/20(G)--   --dict:75/200(L)--   --
dict:75/200(L)--   --dict:106/127(ro)(G)--   --dict:275/300(ro)(G)--   --
dict:24/25(L)--   --dict:4/6(L)--   --dict:25/40(L)--
Current allocation mode is local
Last OS error: 2
GPL Ghostscript 8.63: Unrecoverable error, exit code 1
$ 

poc to reproduce available via email on request.

Comment 1 knud 2009-06-08 09:56:38 UTC

Created attachment 5080 [details]
poc

This is a perl script that can be used to create the malformed file. It has
been tested on ver. 8.64 as well. The offsets differ, but the bug is the same
so it is just a matter of tweaking the buffer / addresses to get code
execution.

Comment 2 Henry Stiles 2009-06-08 10:04:36 UTC

Alex we have agreed to let kokanin@gmail.com (knud) work on this and collect the
bounty, please confirm the bug and review any subsequent patches.

Comment 3 Ray Johnston 2009-06-08 10:19:08 UTC

Interesting that the /BaseFont name is just a skosh over 6800 bytes. This does
not correspond to any buffer sizes, and the maximum name length in the scanner
is supposed to be 16,383 (if EXTEND_NAMES is 0) or 1,023 (if EXTEND_NAMES is 4,
which I _think_ is the default).

Since the PS/PDF scanner is part of the interpreter, Alex is definitely the
correct person for this assignment.

Comment 4 Alex Cherepanov 2009-06-16 20:29:03 UTC

Fix memory corruption caused by long names. The length of name in the scanner
buffer may exceed the maximum name size and should be checked.

The following patch has been committed as a rev. 9797.
http://ghostscript.com/pipermail/gs-cvs/2009-June/009430.html
Regression testing shows no differences.

Comment 5 Alex Cherepanov 2009-06-16 20:29:54 UTC

*** Bug 690522 has been marked as a duplicate of this bug. ***