crash handlers and PTRACE in Ubuntu 10.10

Kees Cook kees at ubuntu.com
Thu Jun 24 18:16:52 BST 2010


On Thu, Jun 24, 2010 at 11:32:28AM +0200, Martin Pitt wrote:
> 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.

That would weaken the protection a bit, but only because the default
coredump ulimit is 0.  So, it sounds like 4 (Apport hooks) is out, and 5
(declared PTRACEing) is more likely if 6 isn't possible.

> 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?

Well, this wouldn't matter since the attacker could still race the signal
handlers after sending SEGV.

-Kees

-- 
Kees Cook
Ubuntu Security Team



More information about the ubuntu-devel mailing list