营销型网站设计建设公司,网站怎么找开发公司吗,建筑网建设通官网,做外贸客户要求看网站报告编号#xff1a;B6-2019-103101报告来源#xff1a;360-CERT报告作者#xff1a;360-CERT更新日期#xff1a;2019-10-310x00 漏洞背景2019年9月6日18#xff1a;00#xff0c;exim发布exim-4.92.2版本修复了CVE-2019-15846#xff0c;攻击者可以利用此漏洞远程获取…报告编号B6-2019-103101报告来源360-CERT报告作者360-CERT更新日期2019-10-310x00 漏洞背景2019年9月6日1800exim发布exim-4.92.2版本修复了CVE-2019-15846攻击者可以利用此漏洞远程获取root权限。漏洞由qualys发现并报告。当exim支持TLS时攻击者发送以0结束的SNI此时string_unprinting函数调用string_interpret_escape函数处理转义序列由于string_interpret_escape函数中没有处理0的情况造成了越界读。qualys已经证实可以利用此漏洞远程获取root权限。2019年10月8日synacktiv发布POC以及漏洞分析360CERT对此进行复现和分析。影响版本exim 4.92.2版本环境搭建(1)poc 地址https://github.com/synacktiv/Exim-CVE-2019-15846将1i7Jgy-0002dD-Pb-D 和1i7Jgy-0002dD-Pb-H 放入/var/spool/exim/input文件夹下需要root权限。(2)启动eximsudo /usr/exim/bin/exim -bd -q30m -ddexim会在启动过程中去读取配置文件执行到string_unprinting()漏洞函数所以不能在启动后用gdb附加,而且启动后的触发漏洞的进程也会退出。根据poc作者的操作是set follow-fork-mode child就可以附加到漏洞进程笔者按该方法无法正常启动exim进行调试所以换了个调试方法在源码触发漏洞前加个等待读取的操作再用gdb去附加漏洞进程。/src/src/spool_in.c:(3)附加漏洞进程(4)进行调试0x01 漏洞分析查找可利用的漏洞触发路径(1)大部分调用string_interpret_escape()的函数都对传入的字符串有限制。例如nextitem()(src/filter.c)检查了字符串缓冲区是否溢出。string_dequote()函数只从配置文件中获取字符串。(2)tls_import_cert()-string_unprinting()-string_interpret_escape()由于证书是pem格式用Base64编码所以不可能包含0序列(3)src/spool_in.cpeerdn(src/spool_in.c)的使用并非默认配置在Exim使用客户端证书验证时才会被调用(4)最后关注到tls连接上只要Exim支持tls连接攻击者就可以发送sni据此调用到string_unprinting() 和 string_interpret_escape() 函数tls_in.sni string_unprinting(string_copy(big_buffer 9));string_unprinting函数的作用是将输入缓冲区的内容(解析转义字符如通过string_interpret_escape函数x62转成b)写入到输出缓冲区。在string_unprinting中判断进入string_interpret_escape流程string_interpret_escape函数中没有对0的判断可以继续读取字符串并写入到输出缓存区中因此造成越界读的同时也越界写了。过程如下图所示刚进入string_unprinting时s 0x1e16de8q ss 0x1e16df0p 0x1e16deeoff 0x6len 0x8第一次memcpygdb-peda$ x/10gx 0x1e16de80x1e16de8: 0x005c666564636261 0x00006665646362610x1e16df8: 0x0000000000000000 0x00000000000000000x1e16e08: 0x0000000000000000 0x00000000000000000x1e16e18: 0x0000000000000000 0x00000000000000000x1e16e28: 0x0000000000000000 0x0000000000000000进入string_interpret_escape前p的值gdb-peda$ p p$24 (const uschar *) 0x1e16dee 进入string_interpret_escape后p的值gdb-peda$ p p$24 (const uschar *) 0x1e16def 退出string_interpret_escape后p指针又自加了一次所以一共自加两次导致向前解析了,0两个字符而0的下一个字符为刚刚memcpy的abcdef不为0所以while循环继续解析导致第二次memcpy:Guessed arguments:arg[0]: 0x1e16df7 -- 0x0 arg[1]: 0x1e16df0 -- 0x666564636261 (abcdef)arg[2]: 0x6 arg[3]: 0x7 第二次memcpy后gdb-peda$ x/10gx 0x1e16de80x1e16de8: 0x005c666564636261 0x61006665646362610x1e16df8: 0x0000006665646362 0x00000000000000000x1e16e08: 0x0000000000000000 0x00000000000000000x1e16e18: 0x0000000000000000 0x00000000000000000x1e16e28: 0x0000000000000000 0x0000000000000000从越界读导致越界写。exgen.py 构造的文件通过对堆的布局(需要在/var/spool/exim/input文件夹下放至少205个message-log文件)通过堆溢出将保存在堆中的文件名修改成../../../../../tmp/tote并伪造sender_address之后该字段保存的字符串会写入message-log文件(即../../../../../tmp/tote)中。但该poc在测试环境中堆无法布局成功(可能环境以及205个message-log文件不同)会覆盖top chunk造成进程崩溃但主进程会重新起进程。使用exgen.py造成的堆布局(进入string_unprinting函数后)如下0x1210c10 0x2e000083 0x4010 Used None None0x1214c20 0x0 0x2020 Used None None0x1216c40 0x0 0x2ff0 Used None None0x1219c30 0x0 0x2020 Used None None0x121bc50 0x0 0x410 Used None Nonegdb-peda$ p s$6 (uschar *) 0x1219ca0 a , x00x00x00x00x00x00x00x00x00x20x00x00x00x00x00x00aaaaaaaaax2ex2ex2fx2e...gdb-peda$ p len$14 0xfc8gdb-peda$ p yield_length $17 {0x20, 0x1ae8, 0xffffffff}之后堆溢出破坏了top chunk0x1210c10 0x2e000083 0x4010 Used None None0x1214c20 0x0 0x2020 Used None None0x1216c40 0x0 0x2ff0 Used None None0x1219c30 0x0 0x2020 Used None NoneCorrupt ?!导致后面分配时错误产生崩溃0x02 补丁分析在string_interpret_escape函数中判断后面是否为0如果是就不再自加一次直接返回所在的地址。退出string_interpret_escape后在string_unprinting自加一次p指针指向0的地址while循环结束不会造成越界读。0x03 时间线2019-09-06 exim发布新版本修复漏洞2019-09-06 360CERT发布预警2019-10-08 synacktiv发布poc2019-10-31 360CERT对外发布漏洞分析报告0x04 参考链接https://www.synacktiv.com/posts/exploit/scraps-of-notes-on-exploiting-exim-vulnerabilities.htmlhttp://exim.org/static/doc/security/CVE-2019-15846.txthttps://git.exim.org/exim.git/blob/2600301ba6dbac5c9d640c87007a07ee6dcea1f4:/doc/doc-txt/cve-2019-15846/qualys.mbx欢迎加入360-CERT团队请投递简历到 caiyuguang[a_t]360.cn
