RE: Stack-Smash Protector

Hmmm, some good insights here.  Seems like stack protection can be an
effective element of a general system security plan, with some caveats.

Let me back up, and proclaim ignorance on behalf of myself and any other
newbies out there.  What code owns stacks that need protection?  Does
everyone share one stack?  If glibc cannot be compiled with stack
protection, does that leave it vulnerable, or does glibc, or do
libraries in general, use the caller's stack?  Is a library wrapper like
libsafe (http://www.research.avayalabs.com/project/libsafe/) a
competitor to, or a complement to, a compilation scheme of inherent
stack protection?

Also, what about the kernel itself?  How vulnerable are its services?
While looking into the gcc patch, I believe I read that the kernel
maintains its own stacks which cannot be protected by that patch because
the kernel "is aware of the structure of its own stacks."  Is this the
protection afforded by a kernel patch such as the GRSecurity patches?
Sorry, I have not yet smartened myself up on kernel patches like
GRSecurity or LIDS.  I intend to.

Thanks,
Dave Maietta

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Ian
Molton
Sent: Monday, September 30, 2002 5:33 PM
To: [email protected]
Subject: Re: Stack-Smash Protector


On Mon, 30 Sep 2002 21:06:53 +0000 (UTC)
[email protected] (Ivo Bitter) wrote:

> > Erk. the cure sounds worse than the disease...
> 
> Yeah... That's why i'm not using it myself :)
> 
> I tried the patch ages ago but other parts of it did Bad Things to my 
> system. They probably fixed that by now though.

Unfortunately, it looks like IA-32 cant protect pages from execution
itself (from my admitteldly brief look at the patch), so I doubt this
can be implemented without horrible penalties as described...

The ARM 26 architecture cant do it either, without the paging hack.

I dunno about ARM32.
-- 
Unsubscribe: send email to [email protected]
and put 'unsubscribe lfs-security' in the subject header of the message

-- 
Unsubscribe: send email to [email protected]
and put 'unsubscribe lfs-security' in the subject header of the message