[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Tinycc-devel] Re: lib/alloca*: mark ELF stack access flags as nonexecut
[Tinycc-devel] Re: lib/alloca*: mark ELF stack access flags as nonexecutable
Thu, 06 Jan 2011 22:03:31 +0100
Thunderbird 18.104.22.168 (Windows/20090812)
Sergei Trofimovich wrote:
How does tcc violate that stack policy?
It always generates execstack binaries (not fixed yet).
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.
Are you saying that the PAX kernel refuses to run anything created
by tcc at all?
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:
nonhardened(standard for most users): (fail/run)
Repasting nonhardened results:
On nonhardened box:
[sf] /tmp/z: # ooops, needs to be fixed!
Here we see execstack is on in tcc generated binary and off on gcc's one.
Well, tcc simply does not specify executable permissions for the stack
so it's neither "off" nor "on" really.
It is just that I have some doubts about a policy which has execstack
"on" by default in the system but then wants everybody to add ugly hacks
into applications to fix this.
But maybe that's just me. Anyway, thanks for the info and links etc.