Exim Ghost Buffer Overflow Exploit

This module is a port to Python of the Metasploit module developed by Qualys for CVE-2015-0235. This module remotely exploits CVE-2015-0235 (a.k.a. GHOST, a heap-based buffer overflow in the GNU C Library's gethostbyname functions) on x86 and x86_64 GNU/Linux systems that run the Exim mail server. Technical information about the exploitation can be found in the original GHOST advisory, and in the source code of this module. SERVER-SIDE REQUIREMENTS (Exim) Summary: if this module's "check" or "exploit" method determines that a remote system is vulnerable, it is probably also exploitable. The remote system must use a vulnerable version of the GNU C Library: the first exploitable version is glibc-2.6, the last exploitable version is glibc-2.17; older versions might be exploitable too, but this module depends on the newer versions' fd_nextsize (a member of the malloc_chunk structure) to remotely obtain the address of Exim's smtp_cmd_buffer in the heap. The remote system must run the Exim mail server: the first exploitable version is exim-4.77; older versions might be exploitable too, but this module depends on the newer versions' 16-KB smtp_cmd_buffer to reliably set up the heap as described in the GHOST advisory. The remote Exim mail server must be configured to perform extra security checks against its SMTP clients: either the helo_try_verify_hosts or the helo_verify_hosts option must be enabled; the "verify = helo" ACL might be exploitable too, but is unpredictable and therefore not supported by this module. CLIENT-SIDE REQUIREMENTS (Impact) Summary: this module's "exploit" method requires the SENDER_HOST_ADDRESS option to be set to the IPv4 address of the SMTP client (), as seen by the SMTP server (Exim); additionally, this IPv4 address must have both forward and reverse DNS entries that match each other (Forward-Confirmed reverse DNS). The remote Exim server might be exploitable even if the Impact client has no FCrDNS, but this module depends on Exim's sender_host_name variable to be set in order to reliably control the state of the remote heap. TROUBLESHOOTING "bad SENDER_HOST_ADDRESS (nil)" failure: the SENDER_HOST_ADDRESS option was not specified. "bad SENDER_HOST_ADDRESS (not in IPv4 dotted-decimal notation)" failure: the SENDER_HOST_ADDRESS option was specified, but not in IPv4 dotted-decimal notation. "bad SENDER_HOST_ADDRESS (helo_verify_hosts)" or "bad SENDER_HOST_ADDRESS (helo_try_verify_hosts)" failure: the SENDER_HOST_ADDRESS option does not match the IPv4 address of the SMTP client (Impact), as seen by the SMTP server (Exim). "bad SENDER_HOST_ADDRESS (no FCrDNS)" failure: the IPv4 address of the SMTP client (Impact) has no Forward-Confirmed reverse DNS. "not vuln? old glibc? (no leaked_arch)" failure: the remote Exim server is either not vulnerable, or not exploitable (glibc versions older than glibc-2.6 have no fd_nextsize member in their malloc_chunk structure). "NUL, CR, LF in addr? (no leaked_addr)" failure: Exim's heap address contains bad characters (NUL, CR, LF) and was therefore mangled during the information leak; this exploit is able to reconstruct most of these addresses, but not all (worst-case probability is ~1/85, but could be further improved). "Brute-force SUCCESS" followed by a nil reply, but no shell: the remote Unix command was executed, but spawned a bind-shell or a reverse-shell that failed to connect (maybe because of a firewall, or a NAT, etc). "Brute-force SUCCESS" followed by a non-nil reply, and no agent: the remote Unix command was executed, but failed to install an agent (maybe because the setsid command doesn't exist, or awk isn't gawk, or netcat doesn't support the -6 or -e option, or telnet doesn't support the -z option, etc).