From owner-freebsd-security Mon Nov 13 10:44:51 2000 Delivered-To: freebsd-security@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id AEF1537B4C5 for ; Mon, 13 Nov 2000 10:44:43 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id KAA19018 for ; Mon, 13 Nov 2000 10:44:43 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda19015; Mon Nov 13 10:44:40 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.1/8.9.1) id eADIiZq16380 for ; Mon, 13 Nov 2000 10:44:35 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdw16374; Mon Nov 13 10:43:41 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.1/8.9.1) id eADIheR11497 for ; Mon, 13 Nov 2000 10:43:40 -0800 (PST) Message-Id: <200011131843.eADIheR11497@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdi11492; Mon Nov 13 10:43:25 2000 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.1.1-RELEASE X-Sender: cy To: freebsd-security@freebsd.org Subject: Re: [MSY] Local root exploit in LBNL traceroute - Part 2 (fwd) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Nov 2000 10:43:25 -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Do we need to concern ourselves about this? Traceroute in -stable is 1.3.2. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC ------- Forwarded Message [headers removed] Date: Sun, 12 Nov 2000 20:16:45 +0100 Reply-To: Michel Kaempf Sender: Bugtraq List From: Michel Kaempf Subject: Re: [MSY] Local root exploit in LBNL traceroute - Part 2 To: BUGTRAQ@SECURITYFOCUS.COM In-Reply-To: <20001106181050.A10333@via.ecp.fr>; from maxx@MASTERSECURITY.FR on Mon, Nov 06, 2000 at 06:10:52PM +0100 Resent-To: cy Resent-Date: Sun, 12 Nov 2000 22:20:44 -0800 Resent-From: Cy Schubert X-UIDL: \Ce!!G7("!2mF!!!9o"! - ---------------[ MasterSecuritY ]--------------- - -----------[ Local root exploit in LBNL traceroute - Part 2 ]----------- - ----------[ By Michel "MaXX" Kaempf ]---------- - --[ 0x00 - Table of contents ]---------------------------------------- -- 0x01 - Brief summary 0x02 - Updating the exploit 0x03 - The exploit versus Non-executable user stack area 0x04 - The exploit versus PaX 0x05 - Credits - --[ 0x01 - Brief summary ]-------------------------------------------- -- The first part of this advisory, available at: ftp://maxx.via.ecp.fr/traceroot/advisory described a known vulnerability in traceroute and a portable way of exploiting the problem. However, the first version of the exploit contained minor imperfections, and could not work against systems protected by the Linux kernel patches from the Openwall Project or the PaX Team. These three issues are discussed in this second part of the advisory. - --[ 0x02 - Updating the exploit ]------------------------------------- -- The new version of the traceroute exploit is available at: ftp://maxx.via.ecp.fr/traceroot/traceroot2.c Two minor imperfections were fixed: - - The memory address of the function pointer overwritten by the exploit, __free_hook, was part of the arch structure in the first version. However, this address will not necessarily be the same on two different computers running the very same operating system. This memory address was removed from the arch structure, and is now provided by the user thanks to the new victim command line argument. - - The first version of the exploit was unable to detect null bytes in the structures it built. The new version of the exploit will return an error if null bytes are found. A workaround exists: the structures can be split into many pieces, allowing null bytes thanks to the string terminators of the command line arguments passed to traceroute. However, the case where null bytes were present, and where no other valid victim could be chosen was never encountered, and that is why the workaround was not implemented. Moreover, "Red Hat Linux release 6.2 (traceroute 1.4a5) i386" support was added. Thanks to fish stiqz, teleh0r and Ady Wicaksono. - --[ 0x03 - The exploit versus Non-executable user stack area ]---------- The first version of the exploit could not work against systems protected by the Linux kernel patch from the Openwall Project (a.k.a. Solar Designer non-executable stack patch), available at: http://www.openwall.com/linux/ Thanks to Alex Khanin for notifying the problem. An exploit against i386 patched systems, which stores the shellcode in the heap instead of the stack, was written and is available at: ftp://maxx.via.ecp.fr/traceroot/openwall.c Following the example of the regular version of the traceroute exploit, the exploit against patched systems requires a few adjustments: - - filename: the full path where the suid traceroute binary can be found. - - p: the pointer returned to the savestr() function by the malloc(1024) call. Check out the first part of the advisory for more information. - - victim: the memory address where the function pointer overwritten by the exploit is stored. __free_hook is not a good choice on patched systems, as its most significant byte is null. The dynamic relocation record of the free() function is a better choice: % objdump -R /usr/sbin/traceroute | grep free 0804c88c R_386_JUMP_SLOT free - - program: the program executed after successful exploitation of traceroute. "/bin/sh" is a possibility, but "/tmp/sh" is another one: % cat /tmp/sh.c #include int main() { char * argv[] = { "/bin/sh", NULL }; setuid( 0 ); setgid( 0 ); execve( argv[0], argv, NULL ); return( -1 ); } - --[ 0x04 - The exploit versus PaX ]----------------------------------- -- The exploit will lose the fight. The return-into-libc technique, or any other technique virtually possible against PaX, will not work against traceroute. The PaX patch is available at: http://pageexec.virtualave.net/ When the exploit overwrites the pointer stored at the memory address foo with the pointer bar, it also overwrites the pointer stored at the memory address bar with the pointer foo (not exactly, two offsets are involved in this process, check out the first part of the advisory, or the unlink() macro used by free(), for more information). This is why a rwx memory page is needed, and (un)fortunately, PaX removes these pages. - --[ 0x05 - Credits ]-------------------------------------------------- -- Again, thanks to Pekka Savola, Chris Evans, Dvorak and Solar Designer. Thanks to Alex Khanin, Eugene Tsyrklevich, fish stiqz, teleh0r, Ady Wicaksono, Matthias Eckermann, Pierre Mondie, Samuel Hocevar and Olivier Thereaux. And thanks to the Securite.Org Team, for providing the best (french) security web site in the world. Check out: http://www.securite.org/ - -- Michel "MaXX" Kaempf ------- End of Forwarded Message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message