Slowloris all the things

At DEFCON, some researchers are going to announce a Slowloris-type exploit for SMB -- SMBloris. I thought I'd write up some comments.


The original Slowloris from several years creates a ton of connections to a web server, but only sends partial headers. The server allocates a large amount of memory to handle the requests, expecting to free that memory soon when the requests are completed. But the requests are never completed, so the memory remains tied up indefinitely. Moreover, this also consumes a lot of CPU resources -- every time Slowloris dribbles a few more bytes on the TCP connection is forces the CPU to walk through a lot of data structures to handle those bytes.

The thing about Slowloris is that it's not specific to HTTP. It's a principle that affects pretty much every service that listens on the Internet. For example, on Linux servers running NFS, you can exploit the RPC fragmentation feature in order to force the server to allocate all the memory in a box waiting for fragments that never arrive.

SMBloris does the same thing for SMB. It's an easy attack to carry out in general, the only question is how much resources are required on the attacker's side. That's probably what this talk is about, causing the maximum consequences on the server with minimal resources on the attacker's machine, thus allowing a Raspberry Pi to tie up all the resources on even the largest enterprise server.

According to the ThreatPost article, the attack was created looking at the NSA ETERNALBLUE exploit. That exploit works by causing the server to allocate memory chunks from fragmented requests. How to build a Slowloris exploit from this is then straightforward -- just continue executing the first part of the ETERNALBLUE exploit, with larger chunks. I say "straightforward", but of course, the researchers have probably discovered some additional clever tricks.

Samba, the SMB rewrite for non-Windows systems, probably falls victim to related problems. Maybe not this particular attack that affects Windows, but almost certainly something else. If not SMB, then the DCE-RPC service on top of it.

Microsoft has said they aren't going to fix the SMBloris bug, and for good reason: it might be unfixable. Sure, there's probably some kludge that fixes this specific script, but would still leave the system vulnerable to slight variations. The same reasoning applies to other services -- Slowloris is an inherent problem in all Internet services and is not something easily addressed without re-writing the service from the ground up to specifically deal with the problem.

The best answer to Slowloris is the "langsec" discipline, which counsels us to separate "parsing" input from "processing" it. Most services combine the two, partially processing partial input. This should be changed to fully validate input consuming the least resources possible, before processing it. In other words, services should have a light-weight front-end that consumes the least resources possible, waiting for the request to complete, before it then forwards the request to the rest of the system.