1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
|
From b9fa1157e1f4982d42241146c9b7c6c789d6f076 Mon Sep 17 00:00:00 2001
From: Ken Sharp <ken.sharp@artifex.com>
Date: Thu, 23 Aug 2018 15:42:02 +0100
Subject: [PATCH 1/5] 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.
CVE: CVE-2018-15911
Upstream-Status: Backport [git://git.ghostscript.com/ghostpdl.git]
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
---
base/aes.c | 3 +++
base/saes.c | 1 +
2 files changed, 4 insertions(+)
diff --git a/base/aes.c b/base/aes.c
index a6bce93..e86f000 100644
--- a/base/aes.c
+++ b/base/aes.c
@@ -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 --git a/base/saes.c b/base/saes.c
index 6db0e8b..307ed74 100644
--- a/base/saes.c
+++ b/base/saes.c
@@ -120,6 +120,7 @@ s_aes_process(stream_state * ss, stream_cursor_read * pr,
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);
--
2.8.1
|
