Date: Mon, 17 Feb 1997 16:59:37 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: cmott@srv.net, msmith@atrad.adelaide.edu.au, freebsd-chat@FreeBSD.ORG Subject: Re: Countering stack overflow Message-ID: <199702170629.QAA08745@genesis.atrad.adelaide.edu.au> In-Reply-To: <199702170607.QAA08532@genesis.atrad.adelaide.edu.au> from Michael Smith at "Feb 17, 97 04:37:50 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- ]] 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 [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702170629.QAA08745>