This simple Python code seems to be successful at DoSing any Python or Ruby XMLRPC server: import xmlrpclib s = xmlrpclib.server("http://127.0.0.1:8001/RPC2") s.cancel("<" * 1000000) This sends about four megabytes of data, the server however takes very long to handle it. The Ruby server I tried this on is still running at full CPU load; it first grew to 120MB in size, but still consumes CPU load without end. Probably it will be done in a day or two. A comparable Python SimpleXMLRPCServer eats 500MB of RAM and gets killed by the ulimits I set up here. On university who don't have such limits but 512MB of RAM and 1024MB of swap, it starts swapping and swapping and eventually gets killed by the kernel. The request, to be downloaded from http://t.div0.ccc-offenbach.org/xmlrpc.http.bz2 (below one kilobyte), does nothing more than POST /RPC2 HTTP/1.0 Host: localhost Connection: close Content-Type: text/xml Content-Length: 4000150 cancel <<<.......................< As you see, the problem seems to be the handling of the entities. Now this is bad when using a standalone XMLRPC server, but requests have to be quite large to exploit it (4MB this time). However, imagine an XMLRPC server supporting Content-Transfer-Encoding: gzip. For example one running as a CGI in Apache. Now that you are imagining that, it shouldn't be hard any more to imagine hundreds, thousands of such CGIs running (that's easy to do since the gzipped request is about four kilobytes). What do we have now? Right, the equivalent of the malloc-fork-and-touch bomb. Is there ANY XMLRPC implementation NOT vulnerable to this rather simple DoS attack (and be it an ugly workaround, like a memory limit for the parser and returning "HTTP/1.0 500 Internal Server Error" if exceeded)? _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/