From owner-freebsd-security Sun Feb 9 15:01:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA16129 for security-outgoing; Sun, 9 Feb 1997 15:01:51 -0800 (PST) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA16119 for ; Sun, 9 Feb 1997 15:01:41 -0800 (PST) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id AAA03828 for ; Mon, 10 Feb 1997 00:01:26 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.4/8.6.12) with UUCP id AAA16030 for freebsd-security@FreeBSD.ORG; Mon, 10 Feb 1997 00:00:50 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.5/keltia-uucp-2.9) id XAA28665; Sun, 9 Feb 1997 23:14:33 +0100 (CET) Message-ID: <19970209231433.QS19404@keltia.freenix.fr> Date: Sun, 9 Feb 1997 23:14:33 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: freebsd-security@FreeBSD.ORG Subject: Re: buffer overruns References: X-Mailer: Mutt 0.60,1-3,9 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT ctm#2999 In-Reply-To: ; from Richard Holland on Feb 9, 1997 12:57:33 -0600 Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Richard Holland: > If I am right here, How would you know just how far you have to go over > and what the characters need to be once you get thus far? Of course I > could be totally wrong here. Realize that I am just now covering > pointers in the book I am reading on C :) Many of the buffer overruns comes from the fact that many "temporary" buffers are allocated from the stack as automatic variables like this: int foo (...) { char tmp [100]; Now imagine tmp is filled with something like this: strcpy (tmp, getenv("SOME_VARIABLE")); If you put enough characters in $SOME_VARIABLE, you could trash, the return address that is usually just before the automatic variables... Realize that the the standard entry instructions for many functions is pushl %bp movl %sp,%bp subl NN,%sp /* where NN is the space for automatic vars */ So the stack will look like this: return address before the call saved %bp ... automatic variables (NN bytes approx.) So if you able to calculate how many bytes the automatic variables will take and put enough data in tmp to overrun all variables *and* the return address, you'll be able to change that return address, making it pointing to a portion of code of *your* doing, like "setuid (0); exec ("/bin/sh");" Most of the buffer overruns are just that, enough data to trash the stack then the exploit code itself. The trick is to calculate offsets just to make the saved %sp from the previous call point to your code. The easiest way to close all this bugs is to make the stack non executable (from a processor standpoint) but I'm not sure you can do it in Intel processors. PS: I'm not sure at all I got the ASM syntax right, I'm still thinking in MASM mode than in GAS mode (reversed operands and all that). PPS: sometimes it pays off to have been an ASM programmer before a C one and to look at what the compiler outputs for a given code... :-) PPPS: ok, it was ASM/370 then 68XXX before even playing with Intel. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #39: Sun Feb 2 22:12:44 CET 1997