-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Folks,
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.
Regards,
- -Phil, pp The Exim Maintainers
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJUx+8WAAoJEE0ekA4UwcwEV5kP/Au8OZTPt1BQjV6cqGlU3KlG
fdRQQQR5zmPHK3UVCIdYd3cPqILbXpsZXKLTSL6g6Nxh+Io9Jd19nRU3bz7tPXAx
mN5b8Eji/CeXfi+nEyXhPndwXENI6XMU4ou0IyP8JaKjJ+rsdiHmGLylDG5xkkig
hsjSmzmXqARdE1R7ponYRyZkw0zohIq1G8Pot6iC/wqhrnBFRsVkIYdVCaSXbUCK
6qEyGqKRIL1K1QQ3XIlLEtblNm5NVzoIL6LXYhkEHWwHAYUBoh4RxqZB4YW70hg+
ubuSWdJkQ1lr05+r0wPrR2Q9K47zgtWhjTLjME1vYUY/pKBmAsZuQZ+0Uqv9Cc6k
EZERucSZ3v7vK/cHlo/mjb77gz6lf5k9LkPPn83w0jdo3u1XQj3I1EbXuARYiXrC
PWFhTaCdBtWpM7OUl1UqKTB5sA24akc6DVYnmD4H1j+WtJFXphObbotZW/8E/xv9
YOk0B1vWRq74B+Rzn4C3H8R/4hU6Um38qlyny98XAgH7FW3zV6nUioceBPTeONV6
1N//xTyPO5vSf5jyIMW8fdGqO6fxs5ZIqyaOcfXecPBdHJL5xyZERK5DG5LLW7Vs
8LBf3+NOrKz3nZ7UoJCAmy7PJDhek+BXSgcvwvjPwsH0T25v7WSTqgff31M/OdMs
dpKT3EnMKq1HRqvWc8E5
=dEzN
-----END PGP SIGNATURE-----
--
## List details at https://lists.exim.org/mailman/listinfo/exim-announce Exim details at http://www.exim.org/ ##
Hash: SHA1
Folks,
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.
Regards,
- -Phil, pp The Exim Maintainers
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJUx+8WAAoJEE0ekA4UwcwEV5kP/Au8OZTPt1BQjV6cqGlU3KlG
fdRQQQR5zmPHK3UVCIdYd3cPqILbXpsZXKLTSL6g6Nxh+Io9Jd19nRU3bz7tPXAx
mN5b8Eji/CeXfi+nEyXhPndwXENI6XMU4ou0IyP8JaKjJ+rsdiHmGLylDG5xkkig
hsjSmzmXqARdE1R7ponYRyZkw0zohIq1G8Pot6iC/wqhrnBFRsVkIYdVCaSXbUCK
6qEyGqKRIL1K1QQ3XIlLEtblNm5NVzoIL6LXYhkEHWwHAYUBoh4RxqZB4YW70hg+
ubuSWdJkQ1lr05+r0wPrR2Q9K47zgtWhjTLjME1vYUY/pKBmAsZuQZ+0Uqv9Cc6k
EZERucSZ3v7vK/cHlo/mjb77gz6lf5k9LkPPn83w0jdo3u1XQj3I1EbXuARYiXrC
PWFhTaCdBtWpM7OUl1UqKTB5sA24akc6DVYnmD4H1j+WtJFXphObbotZW/8E/xv9
YOk0B1vWRq74B+Rzn4C3H8R/4hU6Um38qlyny98XAgH7FW3zV6nUioceBPTeONV6
1N//xTyPO5vSf5jyIMW8fdGqO6fxs5ZIqyaOcfXecPBdHJL5xyZERK5DG5LLW7Vs
8LBf3+NOrKz3nZ7UoJCAmy7PJDhek+BXSgcvwvjPwsH0T25v7WSTqgff31M/OdMs
dpKT3EnMKq1HRqvWc8E5
=dEzN
-----END PGP SIGNATURE-----
--
## List details at https://lists.exim.org/mailman/listinfo/exim-announce Exim details at http://www.exim.org/ ##