Date: Mon, 17 Feb 1997 16:15:18 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: cmott@srv.net (Charles Mott) Cc: msmith@atrad.adelaide.edu.au, freebsd-chat@FreeBSD.ORG Subject: Re: Countering stack overflow Message-ID: <199702170545.QAA08355@genesis.atrad.adelaide.edu.au> In-Reply-To: <Pine.BSF.3.91.970216215017.1692A-100000@darkstar> from Charles Mott at "Feb 16, 97 10:07:11 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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 [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702170545.QAA08355>