Re: Vulnerabilities in Synchronous IPC Designs

[Marcus Brinkmann]

On Mon, Jun 02, 2003 at 11:26:48AM +0200, Jean-Charles Salzeber wrote:
> As stand in
> http://www.eros-os.org/papers/IPC-Assurance.ps
> 
> the L4 IPC system might be vulnerable to DoS attacks.
> What are your opinions about this?

I think that we will need to use a xfer timeout of 0 to prevent a client
from starving the server.  This effectively means that a client must ensure
that all buffer memory is locked down.

As the paper indicates, the only case where this is troublesome is RPCs that
can not be replayed and return variable length data with unbounded size. 
Then locking down memory in advance, or in response to a failed RPC, is not
feasible.

Unfortunately I am not sure that IDL4 is feature-ful enough to allow this
easily.  Temporarily locking down memory is at least possible with
user-level self paging.

The above strategy is roughly equivalent to the truncation option in EROS.
If more advanced strategies are required, we might not be totally out of
luck.  Although the TBO model does not directly transfer to the Hurd, there are
other possibilities like having the trusted physical memory server allocate
memory on the clients behalf for the server's use.  Maybe Neal's container
model can have a wired down option and extended to cover this case.  Such
options have yet to be explored.

Other vulnerabilities in the paper, like exposing the thread ID of the
server thread, are not worrying me.  First of all, the Hurd is intended to be
a general purpose OS and not an extremely reliable OS.  This means that some
type of DoS attacks can be accepted as long as they are accountable and
recoverable.  If there is need for more protection, extensions like quota
mechanisms and wrapping potentially malicious tasks into shells using the
redirector function is not hard to do (the redirector function can restrict
the msgs a thread can send to other threads - for example by blocking or
throttleing them).  At the cost of imposing an overhead on every IPC of
course (the paper claims that this overhead is 20-50 %, but this is with the
clans-and-chief model; I don't know what overhead is imposed by the
redirector.  If you put the redirector into a small address space, it might
be quiete fast).

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/