From: Ken Sharp <ken.sharp@artifex.com>

Date: Thu, 23 Aug 2018 14:42:02 +0000 (+0100)

Subject: Bug 699665 "memory corruption in aesdecode"

Bug 699665 "memory corruption in aesdecode"

The specimen file calls aesdecode without specifying the key to be

used, though it does manage to do enough work with the PDF interpreter

routines to get access to aesdecode (which isn't normally available).

This causes us to read uninitialised memory, which can (and often does)

lead to a segmentation fault.

In this commit we set the key to NULL explicitly during intialisation

and then check it before we read it. If its NULL we just return.

It seems bizarre that we don't return error codes, we should probably

look into that at some point, but this prevents the code trying to

read uninitialised memory.

https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=8e9ce5016db968b40e4ec255a3005f2786cce45f

---

diff -up ghostscript-9.07/base/aes.c.cve-2018-15911 ghostscript-9.07/base/aes.c

--- ghostscript-9.07/base/aes.c.cve-2018-15911	2018-11-23 11:23:38.826259192 +0100

+++ ghostscript-9.07/base/aes.c	2018-11-23 11:25:19.684507346 +0100

@@ -662,6 +662,9 @@ void aes_crypt_ecb( aes_context *ctx,

     }

 #endif

+    if (ctx == NULL || ctx->rk == NULL)

+        return;

+

     RK = ctx->rk;

     GET_ULONG_LE( X0, input,  0 ); X0 ^= *RK++;

diff -up ghostscript-9.07/base/saes.c.cve-2018-15911 ghostscript-9.07/base/saes.c

--- ghostscript-9.07/base/saes.c.cve-2018-15911	2018-11-23 11:25:48.914999536 +0100

+++ ghostscript-9.07/base/saes.c	2018-11-23 11:26:29.903287483 +0100

@@ -120,6 +120,7 @@ s_aes_process(stream_state * ss, stream_

         gs_throw(gs_error_VMerror, "could not allocate aes context");

         return ERRC;

       }

+      memset(state->ctx, 0x00, sizeof(aes_context));

       if (state->keylength < 1 || state->keylength > SAES_MAX_KEYLENGTH) {

         gs_throw1(gs_error_rangecheck, "invalid aes key length (%d bytes)",

                 state->keylength);