crash handlers and PTRACE in Ubuntu 10.10

[Martin Pitt]

Kees Cook [2010-06-22 23:06 -0700]:
> 6) "new kernel heuristic"
>    Find a different heuristic that could apply in these crash cases that
>    would not be vulnerable to the process-hijacking attacks that the
>    PTRACE restrictions are seeking to block.  This is tricky since the
>    crashed processes are usually blocked (but not dead) in their segv
>    handler, so the process isn't strictly _dead_, so I haven't been able
>    to think up ways that such a process is distinguishable from a normal
>    process by the kernel.

In the use cases we are talking about here the process is not even
"crashed", at least not in the sense of "dumped core". Those processes
intercept the SIGSEGV etc. signals with their own handler, so indeed
they are pretty much indistinguishable from a normally running
process.

The only way would be to allow ptracing processes which got a "core
dump" like process sent, i. e. have a per-process flag of
"ptraceable". But then the attacker process could just send sigsegv
signals to the target process and go on, which would make the entire
original idea rather worthless.

Related to that is the suggested option of using Apport. If the
attacker process kill -SEGV's the target process, it can then read all
the target process' memory from the generated .crash file. So the
ptrace protection would not prevent capturing any private data
(passwords, credit card numbers, etc.), but merely stop the attacking
process from being able to silently control the attacked process.

Does the kernel know whether or not a process is currenlty in a signal
handler? If so, perhaps we could allow ptracing processes which
currently are?

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)