About the Ghost vulnerability (glibc)
Today the site qualys publish on their blog a new vulnerability on GNU/Linux system and more precisely on le glibc.
here is the detail : https://community.qualys.com/blogs/laws-of-vulnerabilities/2015/01/27/the-ghost-vulnerability
Here is the debian detail of this bug :
The debian package eglibc is not installed on MailCleaner.
About Exim, this morning Phil Pennock email@example.com wrote this :
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
After a sanity check of the exim's configuration file everything is clean about the HELO/EHLO attack vector.