[lkml]   [2003]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: The disappearing sys_call_table export.
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

[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2005-03-22 13:35    [W:0.218 / U:1.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site