request for verbosity

Discuss usability issues, general maintenance, and general support issues for a grsecurity-enabled system.

request for verbosity

Postby cmouse » Thu Jan 16, 2003 3:47 pm

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
 
Posts: 98
Joined: Tue Dec 17, 2002 10:58 am

Re: request for verbosity

Postby PaX Team » Thu Jan 16, 2003 7:06 pm

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).
PaX Team
 
Posts: 2310
Joined: Mon Mar 18, 2002 4:35 pm

Postby cmouse » Mon Jan 20, 2003 7:00 am

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
 
Posts: 98
Joined: Tue Dec 17, 2002 10:58 am

Postby PaX Team » Mon Jan 20, 2003 7:51 am

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(...)).
PaX Team
 
Posts: 2310
Joined: Mon Mar 18, 2002 4:35 pm


Return to grsecurity support