Re: Stack-Smash Protector
Ian Molton <[email protected]>
| Newsgroups | gmane.linux.lfs.security |
|---|---|
| Organization | The Dragon Roost |
| Message-ID | <[email protected]> |
On Mon, 30 Sep 2002 22:43:24 +0000 (UTC) [email protected] ("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 [email protected] and put 'unsubscribe lfs-security' in the subject header of the message