This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: User Stack Trace


On Thu, Apr 19, 2007 at 09:04:34AM -0700, Stone, Joshua I wrote:
> grundy wrote:
> >They would have to munge the return address for the current function,
> >otherwise there would be no looping :-). An evildoer could certainly
> >set up a bunch of threads that attacked everything and its sister, and
> >existing attack vectors on other products certainly show that sort of
> >sledgehammer nuance. 
> 
> What do you mean by current function?  The topmost in the stack?  A loop 
> anywhere in the stack walk will still cause problems.
Current function meaning whatever function made the syscall that gets
probed. If you mess with the return address the syscall will use
(regardless of method) the program will only have one shot at messing
with us. I think most malicious users would prefer multiple shots before
the program crashes.

> That function does the right thing, but as I said, your first 
> dereference through the loop is unprotected.  Malicious assembly looking 
> something like this would cause a null dereference in the kernel:
> 
> 	push %ebp
> 	mov 0, %ebp
> 	; Now manually trigger the probed syscall
> 	; ...
> 	pop %ebp
> 
> Right?  I'm just pointing out that your first access to the value from 
> nregs->ebp also needs to be protected by _stp_copy_from_user.

ok, I misread that the first time through. The first access to the "value
from nregs->ebp" doesn't leave kernel space. Head actually points
into the regs structure, so it's really printing out the value of
nregs->eax, since it just prints the value it doesn't matter if someone
puts their mom's phone number in there because the first access to the
actual address is through _stp_copy_from_user. 

It's a little weird the way it looks with the frame structure in there,
if you look at arch/i386/oprofile/backtrace.c, you'll see where I got
the ideas from.  They use a recursive function to do the backtrace. I'm
probably going to go back to that method, I was just having some brain
fade while embedding the code, so I made it an ugly loop instead.

If you look in the runtime code in stack.c at the end in the old
_stp_ustack_print, they basically tried the same thing, getting the two
quick values available in kernel space. The side effect of using
sysenter is the eip value points to the vdso and has limited value from
an application programmer's point of view.

Thanks
Mike


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]