Today On This Old Vulnerability

Thomas Ptacek | February 17th, 2006 | Filed Under: This Old Vulnerability

Each week on This Old Vulnerability we try to bring you description of a software vulnerability of Significance. For example, last week’s inaugural episode described Loadmodule2, a cat-and-mouse classic in which 8lgm beat Sun’s IFS environment resetting countermeasure by simply creating two IFS variables. That’s a vulnerability we can file under “clever”.

On today’s episode, we bring you a vulnerability we can file under “sick”: the wu/bsd FTPD signal race.

FTP is a scary protocol. It allows users to upload and download files from remote servers. Non-credentialed Internet users can interact with an FTP server by logging in as “Anonymous”. FTP servers naturally take safeguards to limit what anonymous users can do. In 1997, the state of the art in FTP security countermeasures was to “downgrade” privileges from “root” to “nobody” and chroot the server to an anonymous FTP jail, in which “anonymous” has no privileges to write files.

Unfortunately, for no reason that remained valid in 1996, the FTP protocol introduces needlessly complex connection handling drama. The details we’ll save for a different show (“this old protocol”?), but, suffice it to say, a server managing a single anonymous FTP login has to manage many individual connections. Not only that, but, because FTP is a protocol designed before the select() system call, it uses TCP URG to deliver command-and-control traffic.

Here’s what you need to know about TCP URG to understand the FTP signal race: an application that cares about URG tells the kernel to deliver a signal (SIGURG) when an URG segment is received.

(Here’s what else you need to know about TCP URG in any other situation: nothing).

Here’s what you need to know about signals to understand the FTP signal race: in normal BSD socket code, the receipt of a signal causes a process to perform the moral equivalent of spawning a new temporary thread of control. In FTPD, when SIGURG was received, that thread’s job was to longjump the server back to the command loop to process the new incoming command.

This wouldn’t be a problem except that FTPD also used signals to gracefully handle connection loss. If you abruptly closed one of your FTP connections, the server would get SIGPIPE. It would handle SIGPIPE by performing a logout operation on your behalf.

Here’s what you need to know about FTPD’s logout routine to understand the FTP signal race: it restored the server’s effective UID back to root.

Here’s what happened when a certain Mac FTP client terminated a download by both closing a connection and sending the “ABORT” FTP command to the server: it got silently logged in as root.

More specifically:

1. Closing the data connection generated caused the server to receive SIGPIPE.
2. SIGPIPE caused the server to try to log the client out, restoring the UID to 0 to allow it to clean up. But, just before the server process could exit(),
3. The “ABORT” command, in a TCP URG segment, arrived at the network stack, generating a SIGURG that bounced FTPD out of the SIGPIPE signal handler and into the SIGURG signal handler, which
4. handled the ABORT command by restoring the server process to the FTP command loop to handle the next command.

This was a fun vulnerability check to write (I wrote the Ballista check for it). It worked everywhere, and FTP banners were a poor predictor of it. It’s a race condition, so it takes many (many) attempts to get it right. But you could exploit it with a GUI FTP client just by clicking the “cancel” button a bunch of times.

Here’s more paranoia about Unix signal handling, much of which applies to concurrency in general.

Brought to you in part by a grant from the Jon M. Olin Foundation. Major underwriting for Matasano Chargen is provided by Archer Daniel Midland Company. ADM: Feeding A Hungry World. And of course, readers like you!