Stack-Smash Protector

Ian Molton spyro at f2s.com
Mon Sep 30 16:44:37 PDT 2002


On Mon, 30 Sep 2002 22:43:24 +0000 (UTC)
dave at qix.net ("Dave Maietta") wrote:

First, can I ask you to put your reply /beneath/ the quoted message
please?

> Let me back up, and proclaim ignorance on behalf of myself and any
> other newbies out there.  What code owns stacks that need protection?

ALL code runs with a stack.
 
> Does everyone share one stack?

No. each process / thread has its own stack.

>  If glibc cannot be compiled with stack
> protection, does that leave it vulnerable,

Technically.

> or does glibc, or do
> libraries in general, use the caller's stack?

The callers.

>  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?

not sure - havent had time to look at what it does.

> Also, what about the kernel itself?

I guess that would be architecture dependant.

> 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?

I think that refers to the low level kernel stuff knowing what registers
are on the stored usermode stack. not related.

>From a quick glance the patch appears to make the stack non-executable
by marking stack pages invalid (or something), which would cause a page
fault when it was accessed. The type of access (data or instruction) I
imagine would be determined by the type of pagefault, and the page
're-validated' (or not) before passing control back to userland.
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-security' in the subject header of the message



More information about the lfs-security mailing list