[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: security on Dial-up Systems



On Linux (at least the one I am tinkering with) the user stack is disjoint
from all other processe's stacks and from the kernel's. This means that if
you put code in a buffer such that it overflows and then gets execed it
still runs as user (x). The hack consists in putting the code in a buffer
that is passed to the kernel in a system call and execs when returning
there. Now that implies overflowing a kernel buffer, not a user buffer,
since the guys who wrote most of libc were not born yesterday and
implemented most system calls with access checking etc. On x86 machines an
attempt to overwrite the end of a segment leads to SISGSEGV. Also, the
buffer that needs to be overwritten must be dynamically allocated (i.e. on
the stack). To put this into plain english, if someone can do this then he
is above the average. If he is so and publishes the hack he should be
shot. (just a personal opinion).

On Fri, 1 Aug 1997, Nir Soffer wrote:

> 
> That, if I recall correctly my unix process lessons is incorrect.
> EVery process has a stack of it's own with it's own stack pointers and
> frame pointers. Check out :
> 
> http://millcomm.com/~nate/machines/security/stack-smashing
> 
> for more details. There's even a better article (wfor which I can't recall
> the URL) called 'Smashing the stack for fun and profit' by Aleph One, I
> believe it was published in Phrack magazine.
> 
> 
> Basically, a typical buffer overflow exploit works like so:
> 
> Overflow a buffer that has insufficient bounds checking with the code of
> the exploit you which to execute, overwrite the return IP address to point
> to the beginning of the stack, the code will then be executed.
> 
> Ofcourse, there's a lot more to it, and it's quite hard to explain it
> without knowing how functions in most implementations of C compilsers work
> withut reading the article. So go ahead and read it :)
> 
> HTH,
> Nir.
> 
> On Fri, 1 Aug 1997, Peter Lorand Peres wrote:
> 
> > Anyway, how can someone exec on the stack ?! I think that the 1st thing
> > that happens if you do that while not being root is a SIGSEGV. This
> > because the stack is not necessarily in user space all the time and if it
> > is then it can't do things to the kernel imho. The 'interesting' stack
> > (from the hacking point of view) is in the kernel, i.e. when calling a
> > kernel func from user space to gain some privileges. Am I right ? I am
> > learning programming and I want to 'build' this kind of logic into my
> > programming habits.
> > 
> > Thanks for the nonexec stack URL. 
> > 
> > On Fri, 1 Aug 1997, Ira Abramov wrote:
> > 
> > > On Fri, 1 Aug 1997, Peter Lorand Peres wrote:
> > > 
> > > > Nimrod, where can the non-exec stack patch be gotten (or name 4 searching)
> > > > please.
> > > > 
> > > 
> > >AFAIK, this is the latest version...
> > > 
> > > http://www.linuxhq.com
> > > |
> > > v
> > > http://www.linuxhq.com/upatch20.html
> > > |
> > > v
> > > http://www.linuxhq.com/patch/20-p0491.html
> > > 
> > > 
> > > 
> > > "    I've released a new version of my Linux kernel patch (x86 only) that
> > > makes the stack non-executable.  Now it got some configurable options,
> > > exploit attempt logging, a new flag for ELF/a.out headers, and even some
> > > comments in the source. The whole thing (diffs against 2.0.30 and 2.1.36,
> > > auxiliary tools, and some documentation) are now available.    "
> > > 
> > > download: http://www.false.com/security/linux-stack/linux-stack.tar.gz
> > > 
> > > 
> > 
> > Peter Lorand Peres
> > ------------------
> > plp@actcom.co.il 100310.2360 on CIS (please use Internet address for mail)
> > http://ourworld.compuserve.com/homepages/plp
> > 
> > 
> 
> --
> Nir Soffer AKA ScorpioS. scorpios@cs.huji.ac.il
> "Power corrupts.  Absolute power is kind of neat"
>               -- John Lehman, Secretary of the Navy 1981-1987
> 
> 
> 

Peter Lorand Peres
------------------
plp@actcom.co.il 100310.2360 on CIS (please use Internet address for mail)
http://ourworld.compuserve.com/homepages/plp


Follow-Ups: References: