Re: Vulnerabilities in Synchronous IPC Designs

[Marcus Brinkmann]

On Mon, Jun 02, 2003 at 08:41:26PM +0200, Volkmar Uhlig wrote:
> As mentioned before by Espen, Jonathan refers to the old V2 API. X2/V4
> supports message aborts and restarts for strings.

I assume you mean the offset parameter given for errors 4, 5, 6 and 7.

> So one possible way to
> avoid the DoS is the following:
> 
> - Set receive transfer timeout to zero -- means that the first pagefault
> will abort the IPC
> - Clients have to touch (i.e. read) their message memory before sending
> to make sure/likely it is paged in
> - On pagefault the IPC is aborted immediately. Client and server get the
> total amount of transferred bytes stored in the Error TCR
> - now it is up to a to-be-defined protocol to either restart the message
> or continue at the point of the pagefault

This is barely useful because it would require the server to keep state
between client RPCs.  If the client doesn't follow up with the rest of the
string, the partial string consumes resources in the server, and the server
must be prepared to find them back at the follow up RPC and deallocate them
after some timeout if the client does not behave.  At least you have an
upper bound on the number of such states you need to keep (one per client
thread), but it is cumbersome.

> Alternatively, you can have one dedicated thread per client which
> performs a closed IPC receive and further sandbox malicious clients.

Well, together with the recommendation to have one server thread per CPU
this makes CPU * client tasks threads in the server for waiting on messages. 
If the server has a limit on the number of threads it is allowed to create
(N), a sufficient number of clients (at most N) can collaborate to deny
other clients the service.

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/