Today CVE-2015-0235 was released, concerning a memory mismanagement
vulnerability in glibc's "gethostbyname" functions. This software is
the most common provider of "libc" on GNU/Linux systems, outside of the
embedded space. If you're running Exim on GNU/Linux and don't know
otherwise, assume that you are using glibc to provide much of the base
operating system functionality and that you are affected by this
problem. The latest versions of glibc are not affected, but for clarity
you should check with your OS vendor.
The exploit announcement is up at:
http://www.openwall.com/lists/oss-security/2015/01/27/9
and we'd like to thank Qualys for being exceptionally responsible and
trying to provide us with advance notification that Exim would be
discussed as an exploit vector; unfortunately, the details leaked, they
had to move more quickly than they had planned and we've been left
playing catch-up; we're sorry that this announcement from the Exim
Maintainers is so tardy.
Because glibc is a library, flaws are exposed in applications which use
those functions, so many different programs are affected. Exim was
chosen by the researchers as one widespread possible attack vector, and
they have been able to use this to be able to perform a "remote code
execution" attack against Exim, under certain circumstances.
The best fix is to install security fixes for glibc from your vendor,
and then restart any network services such as Exim.
If you can not sufficiently expedite such changes, then for this one
specific attack vector as outlined in the security advisory, you can
turn off use of the broken library functions by Exim's HELO/EHLO
handling; this does not protect you from other uses of those functions
by Exim, nor does it protect other products. Details below.
The impact of an exploit is to be able to run arbitrary machine code as
the Exim run-time user: the user which handles incoming SMTP
connections. This is typically a user called "exim" (or "_exim" or
"mailnull" or something else chosen by your OS vendor). For a number of
releases now, Exim's code has explicitly blocked ill-advised attempts to
build it with "root" as the run-time user, to limit the consequences of
flaws such as this latest one. Taking over your machine entirely would
require a privilege escalation attack from the Exim run-time user to
root, but attackers just getting a foothold is likely to be sufficiently
painful for you.
To protect Exim against the HELO/EHLO attack vector, do *not* set either
of these in the main configuration:
helo_verify_hosts
helo_try_verify_hosts
and do *not* use the following in any ACLs:
verify = helo
We believe, based on rather hurried analysis, that every other
configuration option in Exim which might use "gethostbyname()" will use
a newer set of functions if available, and not explicitly disabled by
your OS packagers when building Exim.
Likes: 
Quote
