Re: Vulnerabilities in Synchronous IPC Designs

[Marcus Brinkmann]

On Mon, Jun 02, 2003 at 10:18:02PM +0200, Espen Skoglund wrote:
> For certain servers/protocols it certainly makes sense to resend the
> whole message.  For other services it might make sense to only resend
> part of the message.  For example, if a scatter-gather IPC to a
> fileserver is aborted in the middle, the semantics of the agreed upon
> protocol between the server and the client might be that the server
> will commit all the disk blocks which were actually transferred to the
> server.  The client then only needs to resend part of the whole
> message.  No extra state needs to be kept at the server side.

True, this is somewhat similar to what happens if read()/write() are
interrupted by a signal in Unix().

> It is important to remember that aborting IPC operations is an
> exceptional event and should therefore be handled accordingly (i.e.,
> the implementation should not be optimized around handling these
> cases).

I am actually not worried about execution time here but code and
interface complexity, both on the client and server side.  I don't have
right now any specific case that worries me, but in general issues like this
tend to have nasty consequences in the long run, for example with atomicity
of operations, or just with the robustness of the stub code overall.

For DoS attack examination, one also has to take into account that what you
say is an exceptional event can be provoked by the client reliably.  So one
has to ensure that even the exceptional even does not have any negative
impact on the server in an asymmetric trust model.

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/