Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 3 Nov 1999 21:41:48 -0500 (EST)
From:      "Harry M. Leitzell" <Harry_M_Leitzell@cmu.edu>
To:        Paul Hart <hart@iserver.com>
Cc:        Andre Gironda <andre@sun4c.net>, freebsd-security@FreeBSD.ORG
Subject:   Re: stack protecting
Message-ID:  <Pine.SOL.3.96L.991103195319.1577A-100000@unix7.andrew.cmu.edu>
In-Reply-To: <Pine.BSF.4.10.9911031024190.30946-100000@anchovy.orem.iserver.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 3 Nov 1999, Paul Hart wrote:

> On Wed, 3 Nov 1999, Andre Gironda wrote:
> 
> > And I really doubt in either case you prevent 50% of breakins.
> 
> Why?  By a significant margin, most exploitable buffer overflows have
> proven to be of the stack-based variety, and if you've got StackGuard up
> and running I think you'll prevent much more than just 50% of breakins
> from buffer overflows.

	Ounce of prevention is worth a ... You get the point.  I agree
that some sort of buffer overflow prevention in FreeBSD would be loved by
all even if they do not choose to use it.  Anyhow, it would be nice to see
a Stack + Heap Guard that does not break certain aspects of an OS that
people use (gdb modified so that it correctly reads the format of an
activation record on the stack that was changed would be nice).  I am
trying to remember the reason that OpenBSD decided against such designs. 
Anyone? 

> > There is a LOT of material available that explains the inner-workings
> > of heap overflows.  There is a lot of generated code that aids a
> > person with exploiting heap overflows.  They are readily available just
> > like stack overflow exploit scripts are readliy available.
> 
> I agree that heap-based overflows can be exploitable, but they are
> typically more difficult to exploit and seem to be usually less prevalent
> than stack-based overflows.  On other OSes such as Solaris, attacking
> important memory areas such as the procedure linkage table (used for
> dynamic linking) by hitting the stdio FILE structures through an overflow
> in the data/BSS segment has been fruitful in the past, but I don't know
> that we've seen the same for FreeBSD.
> 
> What was the last heap-based overflow exploit for FreeBSD?  The l0pht
> crontab hole or maybe the suidperl 4.x hole?

	Oh come on, if you protect against stack overflows then the main
group of people looking for exploitation in FreeBSD will jump over to the
next easiest thing to look for.  Its not that hard just to focus upon what
you know will work.  Besides, all you need is one way to get root.  The
rest comes later.
	What I am really interested in is how Solaris has a flag that can
be set in /etc/system ( noexec_user_stack ) that does pretty decent stack
overflow protection. I have been looking around for documentation on it,
but haven't found any quite in the detail I want.  I would be interested
in implementing something like this in FreeBSD along with whatever heap
protection I can reason out if someone else is willing to assist or give
me a few pointers. 

> > If you can find a way to stack protect FreeBSD, go for it, I say.  But it's
> > not going to solve every problem.
> 
> I agree, but if it adds at least some protection against the biggest cause
> of holes, why not use it?  I don't think people should use it to give
> themselves a false sense of security though.
> 
> BTW, it *is* possible to use StackGuard on FreeBSD, but it does take some
> hackage to get it to work.

	Hack code would be fine as long as people consider it as a last
resort.  I would be more inclined if someone came up with something that
could be implemented into kernel that could be turned on and off.
	I wonder how the UPT patches were made (Linux, kernel mods if I
remember correctly) and how it got bypassed by ][ceman.  If those over at
sun4c.net care to divulge them, it might be nice to look at and swipe
ideas from.

[-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-]
	Harry M. Leitzell - Harry_M_Leitzell@cmu.edu
		Carnegie Mellon University
		Finger for PGP Public Key
[-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-]



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SOL.3.96L.991103195319.1577A-100000>