stanislav shalunov: netkill

TCP requires its implementations to maintain potentially unlimited state. Since memory is limited (and kernel memory is in most operating systems not ever paged out to disk) this presents a problem.

I demostrate the seriousness of this problem by providing a Perl DoS attack script that can be used against web servers to waste kernel buffer memory. It can consume tens of kilobytes of hard physical kernel memory that will be held for tens of minutes, per packet exchange (each packet exchange involves sending two small packets to the server, with waiting for a response in the middle). This allows an attacker with a decent connection to easily make any reasonable server go out of memory, or it allows a dial-up attacker to take away roughly 30MB of physical memory from a Linux machine. Web servers that have TCP windows tuned for faster transmission will be more vulnerable.

What netkill isn't

• a connect() flood (which establishes connections and holds them open, making the server maintain file descriptors and possibly process table slots associated with them);
• a SYN flood (which doesn't establish any TCP connections, but instead attempts to overwhelm the server with connections in SYN_RCVD state);
• a network bandwidth flood (which attempts to eat all available bandwidth with uninteresting packets).
• anything like 3wahas (which behaves in much the same way as a connect() flood, and is simply a bit faster for daemons that do not print banners, such as HTTP servers).

What netkill is

• a connection is established to the target and an HTTP request is sent;
• a process on the target accepts the connection;
• it reads the request;
• it writes some data (up to 16 or 48KB depending on OS) in response;
• it closes the file descriptor;
• the process that handled the connection now exits or moves on.

The net result is that tens of kilobytes of data are held in kernel space, in non-pageable real RAM until the connection (which is in FIN_WAIT_1 state) times out, which takes tens of minutes. This connection is not associated with any file descriptor or any process.

The RAM used to hold the data is wasted. When we reach a kernel-imposed limit on RAM utilization for network purposes, or when we fill all RAM if no such limit exists in the kernel, the machine panics or locks down. (Tested against large boxes running Linux and FreeBSD.)

The other variation is less severe and more boring and mundane. I call it "process saturation". It lets the processes hang around, thus making this more of a familiar user-space problem and a configuration issue. Which of the scenarios will unfold depends on the size of the requested file (mbufs saturation if it's less than an OS-specific limit).

The source

For historic purposes, my initial BUGTRAQ announcement of netkill (which includes the code and text form of POD documentation) and a brief explanation of netkill (essentially repeating this document) are still available.