[PATCH] Stop DOS attack via packet_recv greediness

[Stefan (metze) Metzmacher]

Sam Liddicott schrieb:
> This patch stop 2 types of client denial of service opportunities, and
> introduces request/response fairness in a server socket.
> 
> 1. As packet_recv normallu slurps up all available socket data with each packet
> it can cause samba to use a lot of memory, and because the data is already
> read from the socket, the client will send more data instead of blocking
> it's send socket.
> 
> e.g. A series of large write requests could come to nearly 64K each and would
> all be read into memory. If a write request takes longer to satisfy than it
> takes for more requests to arrive (perhaps on different handles) then more
> and more memory will be used.
> 
> It is better not to read more data from the socket than we are ready
> to handle, and then tcp itself will deal with throttling the client.
> 
> 
> 2. In the event loop, as 0 time-out timers have higher priority than
> file descriptors, a client can prevent the server from sending responses
> until all available memory is exhausted, by sending a back-to-back series
> of small requests that generate large responses.
> 
> e.g a client can send a very large series of read requests. Because
> packet_recv slurps all data, these requests will be read. Because packet_recv
> uses a timer to process these additional packets, they will be processed before
> previous responses can hit the wire. Because these additional packets
> also slurp all data, this will go on until the incoming socket is empty.
> Because we slurp all data, tcp is not being used for flow control, and so this
> will only be when the client has had enough; thus the server is at the mercy
> of the client.
> 
> 
> 3. For general fairness, new server requests should not prevent the
> sending of server responses.
> 
> This patch only reads from the socket enough bytes to satisfy one packet.
> 
> This patch avoids using timer callbacks to process additional read packets
> when there is pending data and the event loop would re-trigger.
> 
> This final segment may turn out to be a dead case, as generally there will
> not be any additional packets to schedule, but it may trigger in some
> pc->unreliable_select cases.
> 
> Signed-off-by: Sam Liddicott <sam at liddicott.com>
> ---
>  source4/lib/stream/packet.c |   45 +++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 45 insertions(+), 0 deletions(-)

I'll apply this, if it passes make test for me.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.samba.org/archive/samba-technical/attachments/20090519/46d94924/signature.bin