From owner-freebsd-chat Sun Feb 16 21:59:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA26019 for chat-outgoing; Sun, 16 Feb 1997 21:59:03 -0800 (PST) Received: from darkstar (ras514.srv.net [205.180.127.14]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id VAA26014 for ; Sun, 16 Feb 1997 21:58:57 -0800 (PST) Received: (from cmott@localhost) by darkstar (8.6.12/8.6.12) id WAA01761; Sun, 16 Feb 1997 22:58:33 -0700 Date: Sun, 16 Feb 1997 22:58:32 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar To: Michael Smith cc: msmith@atrad.adelaide.edu.au, freebsd-chat@FreeBSD.ORG Subject: Re: Countering stack overflow In-Reply-To: <199702170545.QAA08355@genesis.atrad.adelaide.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-chat@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > 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. The only mechanism I have seen for an intruder to gain control of the executable stream is to rewrite a return address on the stack. I don't see how an overflow of a malloc()'ed buffer can allow someone to gain control of your machine. They may crash it or corrupt operation, but not gain control. Crashing seems to me a much less serious problem. Also it is possible to keep network connection logs to see where intruders came from before the machine died. Charles Mott