Re: breakpoint assistance: single-step out of line

[Jim Keniston <jkenisto at us dot ibm dot com>]

On Fri, 2007-03-16 at 10:54 -0700, Jim Keniston wrote:
> On Fri, 2007-03-16 at 10:09 -0400, Frank Ch. Eigler wrote:
> > Roland McGrath <roland@redhat.com> writes:
> > 
> > > The method of single-stepping over an out of line copy of the
> > > instruction clobbered by breakpoint insertion has been proven by
> > > kprobes.  The complexities are mitigated in that implementation by
> > > the constrained context of the kernel and the fixed subset of
> > > possible machine code known to validly occur in any kernel or module
> > > text.
> > 
> > Another important aspect is that userspace may be hostile.  Beyond
> > just containing oddball instruction sequences, it may deliberately
> > rewrite its own .text, or otherwise interfere with probing in order to
> > produce crashes or security breaches.
> 
> Under what circumstances can a user program rewrite its own text?

Frank answered:
> After an mprotect?

Indeed.  I had to try it to believe it.

> Or someone else doing a ptrace write?

Yes.

OK, here's my next dumb question.  How do you envision a user process
exploiting uprobes to mess up anything but itself (or its ptraced child)
in a novel way?

It could insert breakpoint instructions, but uprobes would let the
resulting SIGTRAPs pass through because they don't match known
probepoints.

It could remove breakpoint instructions inserted by uprobes, but then
the probepoints would never be hit and uprobes would never get involved.

It could scribble on the SSOL instruction slots or the uretprobe
trampoline, with the result that the wrong USER-mode instruction gets
executed, but I don't see how that's anything new that the kernel can't
handle.

I'm not arguing (confidently, anyway) that there are no such exploits.
If you can think of any, I'd like to know them.

Thanks.
Jim