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