1ce4aec2b4
size we receive here should fit into the receive buffer. Unfortunately, there's no 100% foolproof way to distinguish a ridiculously large record size that a client actually meant to send us from a ridiculously large record size that was sent as a spoof attempt. The one value that we can positively identify as bogus is zero. A zero-sized record makes absolutely no sense, and sending an endless supply of zeroes will cause the server to loop forever trying to fill its receive buffer. Note that the changes made to readtcp() make it okay to revert this sanity test since the deadlock case where a client can keep the server occupied forever in the readtcp() select() loop can't happen anymore. This solution is not ideal, but is relatively easy to implement. The ideal solution would be to re-arrange the way dispatching is handled so that the select() loop in readtcp() can be eliminated, but this is difficult to implement. I do plan to implement the complete solution eventually but in the meantime I don't want to leave the RPC library totally vulnerable. That you very much Sun, may I have another. |
||
|---|---|---|
| .. | ||
| Makefile.inc | ||
| xdr_array.c | ||
| xdr_float.c | ||
| xdr_mem.c | ||
| xdr_rec.c | ||
| xdr_reference.c | ||
| xdr_sizeof.c | ||
| xdr_stdio.c | ||
| xdr.3 | ||
| xdr.c | ||