From owner-freebsd-chat Sun Feb 16 21:45:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA25629 for chat-outgoing; Sun, 16 Feb 1997 21:45:39 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA25619 for ; Sun, 16 Feb 1997 21:45:31 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id QAA08355; Mon, 17 Feb 1997 16:15:19 +1030 (CST) From: Michael Smith Message-Id: <199702170545.QAA08355@genesis.atrad.adelaide.edu.au> Subject: Re: Countering stack overflow In-Reply-To: from Charles Mott at "Feb 16, 97 10:07:11 pm" To: cmott@srv.net (Charles Mott) Date: Mon, 17 Feb 1997 16:15:18 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, freebsd-chat@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-chat@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Charles Mott stands accused of saying: > > Not quite sure what you mean here; the stack has to be in the same > > virtual address space as the rest of the program, othewise it wouldn't > > be possible to indirectly reference automatic variables or execute > > trampolies on the stack. > > I thought you were talking about stacks existing in kernel space, as > opposed to user space. Initially, I just want to deal with user space > vulnerabilities. I was, I thought, talking about the user-space stacks. The issue I was referring to was that there are kernel-used data structures mapped just after the user stack, and that the user stack location is used in a number of places for locating this data. (look for the 'kstack' symbol usage in i386/i386) > I think strcpy() can tell whether it is working on an automatic variable > by looking for proximity to the stack pointer. However, it the frame > pointer isn't guaranteed, then strcpy() would not be able to determine an > upper bound for the length of the copy. My point exactly. Even so, it may not be necessary to write that far to cause the program to malfunction/ > In any event, there would be other copy functions to work on also. This would be a particular nuisance with the large volume of third-party source regularly used by FreeBSD users. > What other security holes exist, other than stack overflow variations, > which allow an intruder to take over a machine? That's a restatement of the halting problem. Various examples of common hole-providing behaviour have been discussed on the lists over the last few months. Buffer overflow (rather than stack overflow) errors comprise a large part of the problem, but there have been others (eg. remote login daemons leaking environment variables) which only come to light as the result of a comprehensive code review. > Charles Mott -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[