Date: Thu, 21 May 1998 12:40:01 -0700 (PDT) From: Don Coleman <don@coleman.org> To: freebsd-bugs@FreeBSD.ORG Subject: Re: bin/6627: TCP-based RPC denial-of-service attack Message-ID: <199805211940.MAA17907@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/6627; it has been noted by GNATS. From: Don Coleman <don@coleman.org> To: freebsd-gnats-submit@freebsd.org, trost@cloud.rain.com Cc: Subject: Re: bin/6627: TCP-based RPC denial-of-service attack Date: Thu, 21 May 1998 12:43:50 -0700 This is not a bug, but rather a result of the definitition of ONC RPC plus a result of the common implementation of the RPC libraries (non-multithreaded) and servers we all use. The big problem is that most tcp RPC services can only handle one request at a time, so if a client is intentionally slow, or lies about the data it is going to send, it then ties up the service. A additional issue is that RPC rquests are marsharlled into chunks of data called fragments. They are then further divided on the sender side into a "sendsise" buffer, and collected into a "recvsize" buffer on the receiver side. There is no fixed limit on the "fragment" size, and it isn't a particular type, so xdr doesn't know a type specific size limit either. So if a client lies about how much data it's going to send, the server can't determine it is bogus. The only easy defense is to site behind a firewall or a packet filter, and not allow any "bad" people behind that protection. Throwing in a time-out for data delivery for each tcp connection could reduce the impact of unsophisticated attackers, but anyone willing to write a simple shell script (firing off lots of background processes connecting with telnet to a particular port) could easily swamp the timeout "defense". Long term, baring a change in the specification of the on-wire layout for how RPC moves data and a change in the RPC service API, a reasonably straight- forward solution is to multi-thread all the services, which requires an RPC library supporting multiple threads, plus all the libraries which all the services use. Multithreading them will make it *much* harder for a denial of services attack to succeed, though an attack could impact the performance of a system. Particular services could be protected by using a custom svc_run() routine, which could marshal data on multiple connections, storing the data in a connection specific buffer, until a complete RPC request is built up, but one will need to change the service source code, as you can not use the tranport based RPC API, as they all read from the socket -- you need to use the buffer based version. don --- don@bsdi.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805211940.MAA17907>