[prev in list] [next in list] [prev in thread] [next in thread] 

List:       user-mode-linux-user
Subject:    Re: [User-mode-linux-user] security ??
From:       Jeff Dike <jdike () karaya ! com>
Date:       2000-03-15 7:38:47
[Download RAW message or body]

> 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

[prev in list] [next in list] [prev in thread] [next in thread]