Date: Mon, 13 Nov 2000 10:43:25 -0800 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: freebsd-security@freebsd.org Subject: Re: [MSY] Local root exploit in LBNL traceroute - Part 2 (fwd) Message-ID: <200011131843.eADIheR11497@cwsys.cwsent.com>
next in thread | raw e-mail | index | archive | help
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 <maxx@MASTERSECURITY.FR>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Michel Kaempf <maxx@MASTERSECURITY.FR>
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 <cschuber@osg.gov.bc.ca>
X-UIDL: \Ce!!G7("!2mF!!!9o"!
- ---------------[ MasterSecuritY <www.mastersecurity.fr>
]---------------
- -----------[ Local root exploit in LBNL traceroute - Part 2
]-----------
- ----------[ By Michel "MaXX" Kaempf <maxx@mastersecurity.fr>
]----------
- --[ 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 <unistd.h>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011131843.eADIheR11497>