Date: Mon, 17 Feb 1997 07:30:43 -0700 (MST) From: Charles Mott <cmott@srv.net> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: Michael Smith <msmith@atrad.adelaide.edu.au>, freebsd-chat@FreeBSD.ORG Subject: Re: Countering stack overflow Message-ID: <Pine.BSF.3.91.970217065849.2218A-100000@darkstar> In-Reply-To: <199702170629.QAA08745@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.970217065849.2218A-100000>