|
From: Jeff D. <jd...@ka...> - 2000-03-15 06:42:35
|
> If you decide _not_ to finish the migration to jail, I'd sincerely > love to hear about where those holes in the razor wire even _might_ > exist; it'll make the article more useful. It's definitely on my list. I just haven't done anything about it yet. Big hole #1: The tracing thread's stack is in kernel physical memory. All a hostile process needs to do is zero it out or something, and the tracing thread crashes. Since it was ptracing the hostile process and intercepting its system calls, once it's gone, the hostile process is no longer under control. It now has access to the host system (as whatever user ran the kernel, not as root). Big hole #2: When a process is running process code, its system calls are intercepted. When it is running a system call or trap handler in the kernel, they are not. There is a field in the thread structure which keeps track of this. A hostile process could locate its kernel stack (at the bottom of which is its task structure, which contains the thread structure), and flip that field to fake the tracing thread into believing that its system calls are not to be intercepted. It now has access to the host system. All of the other attacks that I can think of which involve corrupting kernel data also involve crashing the kernel without letting the attacking process out of jail. That's not good, but it's not terrible, especially if the jail is just for that one process. Jeff |