POODLE is a new attack on SSLv3 that makes it easy for a man-in-the-middle
attacker to decrypt web cookies. For details see
https://poodle.io/
The recommended mitigation is to disable SSLv3 and support only TLSv1.x.
However this is liable to cause some interoperability problems to roughly
0.5% of users. For SMTP the main concerns that we know about are old
Android clients and even older Microsoft Exchange servers; a similar
number of newer clients and servers seem to be misconfigured to disable
TLS and support SSLv3 only.
The main concern about being attacked by a POODLE is that your SMTP AUTH
credentials might be compromised. However the web-based version of the
POODLE attack does not apply to email protocols, for reasons set out at
the end of this message, so disabling SSLv3 for email is less urgent.
Nonetheless, this attack is driving a major shift to eliminate the use of
SSLv3 in all protocols, so we can expect future releases of security
libraries to drop support. You should probably try to identify problems
before you have no back-out strategy, by working to eliminate those
clients and servers which do not support TLS. Exim logs cipher suite
details by default, so you can check the size of the problem at your site
by scanning your logs for the string " X=SSL".
To disable SSLv3 in Exim when compiled with OpenSSL, set the following in
the main options section of your configuration file. It affects both
incoming and outgoing connections.
openssl_options = +no_sslv2 +no_sslv3
To disable SSLv3 in Exim when compiled with GnuTLS, set the following in
both the main options section of your configuration file (for incoming
connection) and on your SMTP transports (for outgoing connections).
tls_require_ciphers = NORMAL:!VERS-SSL3.0
The POODLE padding oracle attack requires a certain amount of control over
the plaintext which the attacker is trying to decrypt. Specifically:
(1) The plaintext plus cryptographic checksum has to be an exact multiple
of the cipher block size;
(2) It must be possible to move the secret (cookie or password) embedded
in the plaintext by a byte at a time to scan it past a block boundary.
In the web situation, the attacker can use JavaScript served from anywhere
to make repeated POST requests to an arbitrary target host. The JS can
manipulate the body of the POST to control the overall length of the
request, and can manipulate the request URL path to control the position
of the cookie in the headers.
In the mail situation (POP, IMAP, SMTP), the attacker can make the client
retry requests repeatedly by breaking the connection, but they cannot
control the size or framing of the client's authentication command. The
same reasoning also implies that it isn't feasible to use this attack to
decypt messages; POODLE also requires hundreds of retries to decrypt
each byte, and mail delivery retries are not frequent or persistent
enough.
Tony.
--
<fanf@???> <dot@???>
http://dotat.at/ ${sg{\N${sg{\
N\}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}\
\N}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}
