From owner-freebsd-chat Mon Feb 17 06:31:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA17983 for chat-outgoing; Mon, 17 Feb 1997 06:31:13 -0800 (PST) Received: from darkstar (dialin2.anlw.anl.gov [141.221.252.102]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id GAA17977 for ; Mon, 17 Feb 1997 06:31:10 -0800 (PST) Received: (from cmott@localhost) by darkstar (8.6.12/8.6.12) id HAA02252; Mon, 17 Feb 1997 07:30:54 -0700 Date: Mon, 17 Feb 1997 07:30:43 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar To: Michael Smith cc: Michael Smith , freebsd-chat@FreeBSD.ORG Subject: Re: Countering stack overflow In-Reply-To: <199702170629.QAA08745@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 On Mon, 17 Feb 1997, Michael Smith wrote: > Michael Smith stands accused of saying: > > Charles Mott stands accused of saying: > > > > > > 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. > > > > Think "change the behaviour of a function by altering its local > > variables". > > I should have pointed out here that munging values on the heap is also > quite rewarding. Try spewing "///////////////////.../path/filename" over > the heap on an application that you know writes a private logfile and keeps > the path to said logfile on the heap. > > If you can provide bogus input that gets logged as part of the > message, you may even be able to control what gets put into the file, > again, depending on the application in question. > > You don't have to 'take control' of a program to use it to compromise > system security. I see two major categories of security vulnerabilities: (1) A backdoor which trivially allows someone to become a superuser, bypassing all the normal passwords, security and authentication. (2) Data and file manipulation/corruption leading to either poor system reliability or compromise of privacy Category (1) is far more serious, and seems to warrant some broad and swift moves. The only way that (1) can be achieved, to my knowledge, is through stack overflow. This excepts deliberate back doors or trojan horses placed in the source tree. What is amazing about stack overflow, and really surprised me, is that it is a vulnerability that has been known at least since the Robert Morris Jr. internet Worm attack, almost ten years ago. Yes, a code review is worthwhile, but the OS and basic system calls should provide a layer of defense against stack overflow. It is astonishing that this has not been done yet over the past 5 to 10 years. My own view is that Robert Morris Jr. was not such a bad person, and what he did was actually very instructive. Walking into unix, as I have, really only two years ago, it puzzles me that there have not been more comprehensive solutions. I guess since people working in software think in binary, they see only two states: perfection and everything else. Mathematicians sometimes have the same difficulties when they shift to science or engineering. Charles Mott