grsecurity forums

Jan 16 23:38:14 mordor kernel: PAX: terminating task: /home/cmouse/projects/DDB/ddb(ddb):21129, uid/euid: 1000/1000, EIP: B52DE968, ESP: B52DE964
Jan 16 23:38:14 mordor kernel: PAX: bytes at EIP: e8 13 7c 32 8d cc 00 00 ff ff ff ff 00 00 00 00 00 00 00 00

Just a quick question. _why_ did it kill my task?

I was debugging it with gdb
the process was on 'halt'
and I gave it a command
(gdb)$ print !strcasecmp(value,"value")

cmouse wrote:Just a quick question. _why_ did it kill my task?

I was debugging it with gdb
the process was on 'halt'
and I gave it a command
(gdb)$ print !strcasecmp(value,"value")

PaX kills a process for one single reason only: when it attempts to execute code from a non-executable region. in your case, it was a 'call' instruction (opcode 0xe8) on the stack, probably as a result of gdb injecting it there, as i see an 'int3' (opcode 0xcc) right after that which would have brought control back to gdb. the short answer is that code injecting methods are not compatible with PaX, whether they come from an exploit or gdb matters nothing. solution: chpax -sp your target (not gdb).

I am prolly too stupid because I ask this, but I just want to know why it has to kill it? Wouldn't raising SIGSEGV be enough and preventing the execution?

cmouse wrote:I am prolly too stupid because I ask this, but I just want to know why it has to kill it? Wouldn't raising SIGSEGV be enough and preventing the execution?

sending a SIGSEGV could have two effects: if the task didn't establish a signal handler for it, then it would be killed just like now, if it did, then the handler would be called to try to recover. the question is, do we really want it to, knowing/assuming that we're in the middle of an attack and cannot trust any writable memory in our address space? my decision was that no, we don't want to run *any* userland code after detecting the attack signature, so there will be no signal delivery. if this doesn't fit your purposes, you have the source code and can always change this though (arch/i386/mm/fault.c: do_exit(SIGKILL) -> force_sig_info(...)).