blob: ffff3db526269b0c3862d9b40e896192e10931ac (
plain)
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
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
|
CVE ID: CVE-2016-9963
Date: 2016-12-15
Credits: Bjoern Jacke <bjoern@j3e.de>
Version(s): 4.69 -> 4.87
Issue: If several conditions are met, Exim leaks private information
to a remote attacker.
Conditions
==========
If *all* of the following conditions are met
Build options
-------------
* Exim is built with DKIM enabled (default for newer versions)
exim -bV | grep 'Support.*DKIM'
Runtime options
---------------
* Exim uses DKIM signing (transport options dkim_private_key,
dkim_domain, and other)
* The dkim_private_key option names a file containing the key.
exim -bP transports | grep 'dkim_private_key = .'
* Exim uses PRDR (transport option hosts_try_prdr) (default
since 4.86)
exim -bP transports | grep 'hosts_try_prdr = .'
*OR*
Exim uses the LMTP protocol variant for SMTP transport.
exim -bP transports | grep 'protocol = lmtp'
Operation
---------
* Exim transports a multi-recipient message
* The destination host supports PRDR
OR
the message transport uses LMTP
* One or more recipients are rejected after the DATA phase
Impact
======
Exim leaks the private DKIM signing key to the log files. Additionally,
if the build option EXPERIMENTAL_DSN_INFO=yes is used, the key material
is included in the bounce message.
Fix
===
Install a fixed Exim version:
4.88
4.87.1
If you can't install one of the above versions, ask your package
maintainer for a version containing the backported fix. On request and
depending on our resources we will support you in backporting the fix.
(Please note, that Exim project officially doesn't support versions
prior the current stable version.)
If you think that you MIGHT be affected, we HIGHLY recommend to create
a new set of DKIM keys and fade out the previous DKIM key soon to make
sure that a possibly leaked DKIM key can not be misused in the future.
Workaround
==========
Disable PRDR in your outgoing transport(s): set hosts_try_prdr to an
empty string.
AND do not use the LMTP protocol variant of the SMTP driver.
Indication
==========
You can check if you where affected already. The mainlog entries look like this:
2016-12-17 09:44:33 10HmaX-0005vi-00 ** baduser@test.ex R=client T=send_to_server H=ip4.ip4.ip4.ip4 [ip4.ip4.ip4.ip4]: PRDR error after -----BEGIN RSA PRIVATE KEY-----\nMIICXQIBAAKBgQDXRFf+VhT+lCgFhhSkinZKcFNeRzjYdW8vT29Rbb3NadvTFwAd\n+cVLPFwZL8H5tUD/7JbUPqNTCPxmpgIL+V5T4tEZMorHatvvUM2qfcpQ45IfsZ+Y\ndhbIiAslHCpy4xNxIR3zylgqRUF4+Dtsaqy3a5LhwMiKCLrnzhXk1F1hxwIDAQAB\nAoGAZPokJKQQmRK6a0zn5f8lWemy0airG66KhzDF0Pafb/nWKgDCB02gpJgdw5rJ\nbO7/HI3IeqsfRdYTP7tjfmZtPiPo1mnF7D1rSRspZjOF2yXY/ky7t7c5xChRcSxf\n+69CknwjrfteY9Aj0j6o7N+2w2uvHO+AAq8BHDgXKmPo0SECQQDzQ/glyhNH9tlO\nx+3TTMwwyZUf2mYYosN3Q9NIl3Umz/3+13K5b6Ed6fZvS/XwU55Qf5IBUVj2Fujk\nRv2lbGPpAkEA4okpnzYz5nm1X5WjpJPQPyo8nGEU1A5QfoDbkAvWYvVoYrpWPOx5\nHFpOAHkvSk1Y1vhCUa+zHwiQRBC8OMp6LwJBAOAUK/AjQ792UpWO9DM++pe2F/dP\nZdwrkYG6qFSlrvQhgwXLz5GgkfjMGoRKpDDL1XixCfzMwfVtBPnBqsNGJIECQGYX\nSIGu7L7edMXJ60C9OKluwHf9LGTQuqf4LHsDSq+4Rz3PGhREwePsMqD1/EDxEKt4\noHKtyvyeYF28aQbzARMCQQCRtJlR6vlKhxYL8+xoPrCu3MijKgVruRUcNstXkDZK\nfKQax6vhiMq+0qIiEwLA1wavyLVKZ7Mfag+/4NTcDUVC\n-----END RSA PRIVATE KEY-----\n: 550 PRDR R=<baduser@test.ex> refusal
Even if there is no evidence in the existing log files, that a DKIM key
leakage happened this might have happened in the past, log files might
have been deleted already but a key leak could have ended up via mail
bounce in a user mail box
|
