On Sat, May 10, 2003 at 10:18:34PM +0300, Yoav Weiss wrote:
> Masud, your delay-based solutions won't work because an attack code can
> just keep running in a loop until it gets the timing right. Once is
> enough. Even if it could work, it would have impact on the whole system.
> Afaik, you can't really yield the CPU for very short time slices so you'll
> have to busy-loop instead, and its not acceptable. I believe the below
> solution is the right one. Arjan, please correct me if I'm wrong.
>
> The solution is to have only ONE REAL copy, done by the wrapper. The
> original syscall will copy from a kernel ptr, unknowingly. Consider
> the following modified pseudo-code:
>
> long your_wrapped_syscall(char *userfilename)
> {
> char kernelpointer[something];
> copy_from_user(kernelpointer, usefilename, ...);
> audit_log(kernelpointer);
> old_fs = get_fs();
> set_fs(KERNEL_DS);
> ret = original_syscall(kernelpointer);
> set_fs(old_fs);
> return ret;
> }
>
> userfilename is only copied once. original_syscall just copies
> kernelpointer again, to another kernel pointer. No race.
This approach, while it would solve this particular problem, has a
grave flow. Consider the case where the first copy in the
original_syscall is to copy a user space structure, which has embedded
user space pointers... The set_fs() will cause future
copy_from_user/copy_to_user in original_syscall() calls to succeed
even if the user supplied pointer is in kernel space.
> Removing this symbol will not really get in the way for the bad guys
> because it'll always be possible to find and intercept it anyway (see my
> previous post in this thread), but it'll increase the learning curve for
> kernel newbies. Do we really want that ?
Hear hear.
-- Muli Ben-Yehuda http://www.mulix.org
This archive was generated by hypermail 2b29 : Thu May 15 2003 - 22:00:34 EST