Please educate a curious cat

Posted Aug 16, 2007 13:27 UTC (Thu) by kleptog (subscriber, #1183) [Link]

I think the point is that the system call wrapping was supposed to be cheap and quick, hence the wanting to avoid copying the data twice. The wrapper gets the data exactly the same way as the system call.

What you suggest (copying data then checking) is I think pretty much what the LSM do. Rather than just wrapping the system call, it gets called *after* the kernel has copied it to kernel space. This it's safer, but not as easy to write...

Posted Aug 16, 2007 13:52 UTC (Thu) by kilpatds (subscriber, #29339) [Link]

As one of the authors of GSWTK.... (We knew about the issue. GSWTK was
a research project, not intended for production use)

We stopped working on it before the vsyscall method was adopted, so
please limit these comments to the software interrupt syscall method.

Someone has to copy in all "complex" data into kernel space before
operating on it. In linux, that is done by the sys_* methods that
implement the system calls.

GSWTK Wrappers replace the system call vector, so they are called before
the sys_* call. So the wrapper has to copy in the data to analyze it,
but has to hand the original system call a pointer that can be copied in.
That is, a pointer in user space.

We could copy the data to somewhere else in userspace (a page we allocate
in their process space), make that page not writable by the program, and
pass that pointer in. But this is just a band-aid. The process could
reset the flags on the page and change the data. It just shrinks the
race period. It doesn't fix the fundamental race.

If one were a kernel developer who wanted to support wrapper-like
interposition, you could add a layer to enable it. The base system call
would copy data in, then call the method that actually implemented the
logic. This would provide an alternate interposition point. But it
would slow everyone else down. I can't imagine such a feature making it
in.

Doug

Posted Aug 16, 2007 14:35 UTC (Thu) by dwheeler (guest, #1216) [Link]

Correct; the attacks ONLY work if the design permits race conditions. The notion that user-space data will stay unchanged during a kernel call is untrue is practically all of today's OSs, and this attack worked in the 1960s and 1970s too (it's well-documented). The solutions are well-documented, too; eliminate the race condition. The "easy" way is to copy all data into the kernel, and then use that protected version. The trick is to get good performance as well.