tinycc-devel
[Top][All Lists]
Advanced

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

[Tinycc-devel] Re: lib/alloca*: mark ELF stack access flags as nonexecut


From: Sergei Trofimovich
Subject: [Tinycc-devel] Re: lib/alloca*: mark ELF stack access flags as nonexecutable
Date: Thu, 6 Jan 2011 22:23:05 +0200

On Thu, 06 Jan 2011 20:25:51 +0100
grischka <address@hidden> wrote:

> Sergei Trofimovich wrote:
> >> How does tcc violate that stack policy?
> > 
> > It always generates execstack binaries (not fixed yet).
> 
> [...]
> 
> > $ ./main.tcc 
> > Killed
> > PAX: terminating task: /tmp/z/main.tcc(main.tcc):17706, uid/euid: 
> > 1000/1000, PC: 0000719781b5175f, SP: 0000719781b51748
> 
> However that would mean that tcc does NOT generate execstack binaries.
> (Unless the reason for the crash is something else.)

It does, but PAX kernel (a set of patches on top of vanilla kernel
 http://pax.grsecurity.net/docs/) won't allow you to run (or operate
suspiciously) a binary with any static or dynamic mapping of Writable
and eXecutable bits enabled for _any_ vma to exist in kernel.

For example if you will try to workaround page permissions  for mmap/mprotect 
you'll get an
error from syscall.

I've posted 2 results:
    hardened: fail/failone
and
    nonhardened(standard for most users): (fail/run) 

Repasting nonhardened results:
> On nonhardened box:
> $ ./main.gcc
> Segmentation fault

> [sf] /tmp/z:./main.tcc 
> [sf] /tmp/z: # ooops, needs to be fixed!

Here we see execstack is on in tcc generated binary and off on gcc's one.

-- 

  Sergei

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]