Re: User Stack Trace

["Stone, Joshua I" <joshua dot i dot stone at intel dot com>]

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.

> > Or, for that matter, the program could just restore the correct return 
> > address before it returns...
> I don't think that is practical, though it would be handy to have a
> sys_my-stack-is-hosed-please-fix-my-program() ^_^

Ha -- shall we submit such a syscall upstream?

Remember though that a syscall can be triggered manually (through INT 
80, SYSCALL, or SYSENTER), so I can make my register state look like 
anything I want before entering the kernel.

> > Or a more direct concern, even for non-malicious programs, what if the 
> > memory at %ebp is paged out?  This is unlikely, but it's still possible, 
> > right?  I think this first access to %ebp must be protected by a 
> > _stp_copy_from_user as well.
> _stp_copy_from_user does the right thing, checks access and returns a
> null string if the location isn't available. 

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.


Josh