[Top][All Lists]
[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
signature.asc
Description: PGP signature