CVE-2018-6789

पर्यावरण सेटअप

निर्भरताएँ स्थापित करें

apt-get install gcc net-tools vim gdb python wget git make procps libpcre3-dev libdb-dev libxt-dev libxaw7-dev

exim का पुराना संस्करण डाउनलोड करें

wget ftp://mirror.easyname.at/exim-ftp/exim/exim4/old/exim-4.89.tar.gz
tar -xvzf ./exim-4.89.tar.gz
cd ./exim-4.89
cp src/EDITME Local/Makefile
cp exim_monitor/EDITME Local/eximon.conf

फिर Local/Makefile संशोधित करें सुविधा के लिए सभी फ़ोल्डर वर्तमान निर्देशिका की ओर इंगित करें

BIN_DIRECTORY=/home/zzx/EVA/cve-2018-6789/exim-4.89/bin
CONFIGURE_FILE=/home/zzx/EVA/cve-2018-6789/exim-4.89/configure
SPOOL_DIRECTORY=/home/zzx/EVA/cve-2018-6789/exim-4.89/exim
EXIM_USER=zzx
AUTH_PLAINTEXT=yes
AUTH_CRAM_MD5=yes
AUTH_TLS=yes

इससे डिबग करना आसान हो जाता है फिर संकलन और स्थापित करें

make install

./configure को संशोधित करें, नीचे दी गई सामग्री से सीधे ओवरराइट करें

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

चलाना

./bin/exim -bd -d-receive

भेद्यता विश्लेषण

पहले base64.c में पैच का विश्लेषण करें: यहाँ result base64 डिकोड परिणाम के लिए बफ़र है, जिसे store_get फ़ंक्शन द्वारा प्राप्त किया गया है यह देखा जा सकता है कि पैच से पहले size की गणना में समस्या है; जब size 4n~4n+3 की सीमा में होता है, तो गणना की गई size की लंबाई समान होती है, लेकिन b64decode जब पैरामीटर 4 के गुणज नहीं होते, तो डिकोड करते समय एक या दो बाइट अधिक डिकोड हो जाते हैं

उदाहरण के लिए, हम सीधे भेजते हैं

auth_md5('Hf'*42)

size=0x40
परिणाम का मेमोरी वितरण:

pwndbg> hexdump 0x711d60 0x50
+0000 0x711d60  1d f1 df 1d  f1 df 1d f1  df 1d f1 df  1d f1 df 1d  │....│....│....│....│
+0010 0x711d70  f1 df 1d f1  df 1d f1 df  1d f1 df 1d  f1 df 1d f1  │....│....│....│....│
+0020 0x711d80  df 1d f1 df  1d f1 df 1d  f1 df 1d f1  df 1d f1 df  │....│....│....│....│
+0030 0x711d90  1d f1 df 1d  f1 df 1d f1  df 1d f1 df  1d f1 df 00  │....│....│....│....│
+0040 0x711da0  20 61 61 61  61 61 61 61  61 61 61 61  61 61 61 61  │.aaa│aaaa│aaaa│aaaa│

फिर प्रयास करें

auth_md5('Hf'*42+'HfH')

size=0x40

pwndbg> hexdump 0x711d60 0x50
+0000 0x711d60  1d f1 df 1d  f1 df 1d f1  df 1d f1 df  1d f1 df 1d  │....│....│....│....│
+0010 0x711d70  f1 df 1d f1  df 1d f1 df  1d f1 df 1d  f1 df 1d f1  │....│....│....│....│
+0020 0x711d80  df 1d f1 df  1d f1 df 1d  f1 df 1d f1  df 1d f1 df  │....│....│....│....│
+0030 0x711d90  1d f1 df 1d  f1 df 1d f1  df 1d f1 df  1d f1 df 1d  │....│....│....│....│
+0040 0x711da0  f1 61 61 61  61 61 61 61  61 61 61 61  61 61 61 61  │.aaa│aaaa│aaaa│aaaa│

दो बाइट ओवरफ्लो हो गए

Exim मेमोरी प्रबंधन तंत्र

Exim ने प्रदर्शन बढ़ाने के लिए मौजूदा हीप प्रबंधन तंत्र के ऊपर अपना स्वयं का मेमोरी प्रबंधन तंत्र लागू किया है, यह कोड और glibc के बीच एक मध्यवर्ती बफर के रूप में कार्य करता है, जिसका उद्देश्य malloc और free की संख्या को कम करना है Exim के लिए एक अलग हीप ब्लॉक को storeblock कहा जाता है, हर बार उपयोग में इससे उपयुक्त आकार का बफर काटा जाता है; यदि एक storeblock समाप्त हो जाता है, तो एक नया storeblock malloc किया जाता है। प्रत्येक storeblock के लिए, इसकी संरचना एक सरल एकल लिंक्ड लिस्ट है:

/* Structure describing the beginning of each big block. */
typedef struct storeblock {
  struct storeblock *next;
  size_t length;
} storeblock;

प्रोग्राम हीप का उपयोग करते समय मुख्य रूप से store.c में API का उपयोग करता है:

store_get
store_release
store_extend
store_reset

इनमें से store_get का उपयोग बफ़र प्राप्त करने के लिए किया जाता है, महत्वपूर्ण कोड इस प्रकार है:

128 void *
129 store_get_3(int size, const char *filename, int linenumber)
....
145   int length = (size <= STORE_BLOCK_SIZE)? STORE_BLOCK_SIZE : size;
...
161   /* If there was no free block, get a new one */
162 
163   if (!newblock)
164     {
165     pool_malloc += mlength;           /* Used in pools */
166     nonpool_malloc -= mlength;        /* Exclude from overall total */
167     newblock = store_malloc(mlength);
...

यह देखा जा सकता है कि हर बार आवंटित store_block की न्यूनतम लंबाई STORE_BLOCK_SIZE है, जो 8192 है

इसलिए एक 8192 आकार के store_block, उसके संरचना शीर्ष और हीप ब्लॉक शीर्ष के साथ कुल आकार 0x2020 होता है

जब exim क्लाइंट द्वारा भेजे गए निर्देश को निष्पादित करता है, यदि निर्देश सफलतापूर्वक निष्पादित होता है, तो store_reset को कॉल करके अनावश्यक कैश और अतिरिक्त store_block को मुक्त कर देता है।
यहाँ सफल निष्पादन का अर्थ है कि निर्देश का प्रारूप सही है, मेलबॉक्स में अवैध वर्ण नहीं हैं, आदि; अन्यथा store_reset कॉल नहीं होगा।

उपयोग रणनीति

यह भेद्यता एक क्लासिक off-by-one है (हालाँकि वास्तव में दो बाइट ओवरफ्लो हो सकते हैं), लेकिन ओवरफ्लो बाइट्स की संख्या कम है, इसलिए हीप ब्लॉक पर संवेदनशील संरचना को सीधे ओवरराइट नहीं किया जा सकता है। इसलिए, इस भेद्यता के प्रभाव को बढ़ाने के लिए ptmalloc की कुछ विशेषताओं का उपयोग करने की आवश्यकता है, इसे व्यापक overflow या overlap में बदलना होगा।
off-by-one भेद्यता के लिए, एक क्लासिक उपयोग विधि chunk enlarge -> chunk overlap है, हीप ब्लॉक के size को बड़ा करके, फिर glibc सैनिटी चेक को बायपास करने के लिए एक नकली हीप हेड बनाकर, ताकि हीप ब्लॉकों का ओवरलैप हो और व्यापक कवरेज हो सके।

यहाँ मुख्य प्रक्रिया chunk enlarge -> chunk overlap -> storeblock में next pointer को दूषित करना है, फिर store_reset को ट्रिगर करके एक मनमाना हीप ब्लॉक को free करना है, और इस ब्लॉक को फिर से आवंटित करके इसकी सामग्री को संशोधित करना (type confusion) है। meh ने लेख में ACL स्ट्रिंग वाले हीप ब्लॉक को संशोधित करने की सिफारिश की है, क्योंकि ACL स्ट्रिंग प्रोसेसिंग में एक कमांड निष्पादन फीचर है। ACL स्ट्रिंग्स बहुत अधिक हैं, लेकिन अधिकांश NULL हैं (संभवतः कॉन्फ़िगरेशन फ़ाइल से संबंधित), यहाँ मैंने acl_smtp_mail स्ट्रिंग को चुना है, जिसमें कमांड निष्पादन का सिंटैक्स है:

${run{command}}

लगभग हीप लेआउट इस प्रकार है:

इसमें पहला हीप ब्लॉक base64 डिकोड से प्राप्त ब्लॉक है, जिसका उपयोग off-by-one के लिए किया जाता है, इसलिए इसे एक storeblock के अंत में होना चाहिए। सुविधा के लिए यहाँ सीधे 0x2020 से बड़ा ब्लॉक आवंटित किया गया है जिसमें base64 डिकोड परिणाम संग्रहीत होता है;
दूसरा हीप ब्लॉक sender_helo_name है, जिसका उपयोग अगले हीप ब्लॉक को ओवरराइट करने के लिए किया जाता है। sender_helo_name storeblock में संग्रहीत नहीं होता, बल्कि सीधे malloc किया जाता है:

1832 static BOOL
1833 check_helo(uschar *s)
1834 {
...
1884 if (yield) sender_helo_name = string_copy_malloc(start);

इसलिए आकार इच्छानुसार हो सकता है;
तीसरा हीप ब्लॉक base64 डिकोड से प्राप्त ब्लॉक है, जिसका उपयोग मुख्य रूप से नकली हेड बनाने और ओवरराइट किए जाने के लिए किया जाता है, इसलिए इसे एक storeblock की शुरुआत में होना चाहिए। सुविधा के लिए सीधे 0x2020 आकार आवंटित किया गया है।

शोषण

मेरा शोषण भी इंटरनेट पर अन्य लोगों के विश्लेषण का अनुसरण करके कदम दर कदम प्राप्त किया गया है। मूल विचार समान है, लेकिन हीप का लेआउट दूसरों से थोड़ा अलग है, इसलिए कुछ छोटे पैरामीटर भिन्न हैं।