Hi, I've discovered a remote buffer overflow in the bootpd daemon that, to my knowledge, is distributed with most linuxs and bsds. However, due to the characteristics of the vulnerability, a good portion of the operating systems with the bug are probably not vulnerable to a remote code execution situation. In that situation, bootpd is still vulnerable to a remote crash, which may or may not have an impact. Specifically, I have been able to write a working remote exploit for OpenBSD, and a friend of mine has created a working BSDI exploit. OpenBSD released patches to fix this problem on Nov. 28th of this year. These patches should be appropriate for other versions, and they are available at ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/bootpd.patch. I checked out some operating systems, and determined that freebsd, and the linux distributions that I checked (slackware and debian) were not vulnerable to remote code execution. I have not attempted to determine if Solaris, Irix, Digital Unix, or any other OS's are vulnerable. The vulnerability is in bootpd.c: ... hlen = haddrlength(bp->bp_htype); if (hlen != bp->bp_hlen) { report(LOG_NOTICE, "bad addr len from %s address %s", netname(bp->bp_htype), haddrtoa(bp->bp_chaddr, hlen)); } dummyhost.htype = bp->bp_htype; bcopy(bp->bp_chaddr, dummyhost.haddr, hlen); hashcode = hash_HashFunction(bp->bp_chaddr, hlen); ... bp_htype is an unsigned character value taken out of the packet that was sent. You can see here that the bcopy will copy hlen bytes out of the packet onto a structure on the stack. hlen is what haddrlength returns, given our htype from the packet. haddrlength is a macro: ... #define haddrlength(type) ((hwinfolist[(int) (type)]).hlen) ... hwinfolist is a table that matches up types to a length and description. It is a predefined array of about 10 instances of this struct: struct hwinfo { unsigned int hlen; char *name; }; The problem is that we can specify a htype that is past the end of the hwinfolist table. Thus, we can address the memory that resides after this structure, potentially finding a value that will be appropriately aligned to give us a sufficient amount of bytes to overwrite the stack. There is another potential problem with exploitation: if the bp_hlen field in the packet does not equal the hlen returned from the macro, then it prints a warning. When it prints this warning, it dereferences the pointer to the description given in the hwinfolist table. We can control the bp_hlen field, but it is only an unsigned character, so if the value we pick in memory for the number of bytes to copy is greater than 255, then the next value in memory has to be a valid pointer. Exploitation is aided by the fact that you can jump into the buffer read into the data segment from the socket, thus placing few limitations on the size and contents of your shell code, and potentially bypassing stack patches. horizon
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:24:32 PDT