by Rik Farrow
March 2003 brought more than spring weather. Five vulnerabilities, all exploitable from the Internet, appeared in March, along with published exploits for two of them. The appearance of these vulnerabilities had system administrators scrambling to find all vulnerable systems and install patches on them because all but one of these vulnerabilities provided privileged access. Several of these vulnerabilities might even be the hole used by the next fast spreading worm.
As I listened to my colleagues complain about how difficult a time they were having tracking down vulnerable systems, I found myself wondering about firewalls. These people all work at organizations protected by firewalls. Weren't firewalls supposed to be protecting the "soft, chewy inside" from external threats? Certainly, good system administrators would still patch these vulnerabilities, as the Slammer worm had recently showed just how porous even firewall protected networks can be. But it seemed to me that if system administrators could rely on their firewalls to at least block the latest set of threats, they could handle upgrading servers in less of a panic.
I set about contacting some firewall vendors, and asking them if their firewall could have blocked the recent attacks. What I learned has a lot to teach all of us about the state of Internet security today.
Before you even consider contacting your firewall vendor's support team, or checking their web site for bulletins, you need to know if your firewall product can even block attacks in traffic that is permitted through your firewall. Most firewalls today rely on a technique known as Stateful Packet Filtering (SPF), sometimes given trademarked names by vendors. In an SPF-based firewall, traffic gets passed through a firewall based first on a set of configurable rules, with subsequent traffic getting passed based on state. For example, a request from an internal user's Web browser gets permitted out through the firewall based on a rule that permits that traffic. The response, however, gets passed back through the firewall to the user based on the state that was setup when the initial traffic was permitted through the firewall. The firewall remembers that it had permitted the outgoing traffic, and saves this information as state (in a state table).
This technique turns out to be very efficient, as it is faster for a firewall to check the state table to see if a packet is permitted than it is to check the rules. The firewall administrator also gets a break, because he or she only has to set up the rule for outgoing packets (in this example), and the state mechanism handles the incoming responses.
SPF can even do fancier things, like create temporary state based upon the content of a packet. Configuring packet filter firewalls to handle FTP (in active rather than passive mode) leaves gaping holes in a firewall. SPF handles active mode FTP much more gracefully. When an FTP control packet passes through the firewall that requests that a remote server makes an inbound connection to the client, the SPF firewall creates state that allows this incoming connection. This mechanism has been subject to abuse, such as when some security investigators showed how state could be created by using a carefully crafted error message, and arbitrary holes opened in an SPF firewall. That particular vulnerability has been fixed (with a kludge that has worked fine so far).
Some vendors use a different technique for passing traffic through the firewall and getting responses back. Instead of using rules and state, these firewalls use TCP connections as a form of state. SOCKs has been the most popular software used to do this, and used to be called a circuit relay, as the SOCKs software would create an internal connection and an external one, and relay packets between the inside and the outside of the firewall. Over time, circuit relays became known as proxies, as the circuit relay could also be said to "proxy" the connection.
These firewall methodologies have a weakness, or perhaps you could say they make a tradeoff. Neither SPF nor circuit relays does anything to verify the correctness of any request or response that gets sent through the firewall. All Internet protocols follow standards, defined in the RFCs, for the formats that valid requests and responses must take. Some of these formats appear as plain text, such as HTTP and SMTP. Others, like DNS, use a binary format, which a human would have a difficult time understanding, but is actually easier for a program to parse. SPF and circuit relays ignore this information, and base their decisions on the Internet and transport layer headers (layers two and three) instead.
A firewall that checks the formats of requests and replies must actually implement a lot of the underlying application. This firewall technique used to be called an application gateway, or AG, since an application formed the gateway between internal and external networks. Over time, AGs began to be called proxies, leading to confusion between the much simpler circuit relays and the more secure AGs.
Vendors write each application gateway specifically for the protocol being handled. For example, an HTTP AG only handles HTTP traffic, and can read both the request and the response headers and check the headers to see if the data match the approved format. The AG can do more than check the request and response header information, but can also check to see if the content of the response is permitted. An SMTP AG could potentially block email attachments based on MIME-type or filename extension--something that most SMTP AGs can do.
Part of the header checking performed by many SMTP AGs includes preventing overly long addresses or lines in email headers. RFC 821 suggests sizes for usernames, domains, commands, and text lines (section 4.5.3), and these constraints, when properly built-into an AG, would prevent the recent SMTP exploits from passing through the firewall. SPF and circuit relay firewalls cannot provide this level of protection. Instead of protection, these firewalls deliver performance, a decision that some firewall owners may learn to regret.
March 2003 began with the announcement of a sendmail vulnerability. Sendmail servers handle more than half of all the email on the Internet. Sendmail servers, as well as other email servers handling Internet email, are situated on internal networks and are accessible through any firewall, making them exciting targets for attackers. Sendmail also runs as root, the most privileged UNIX/Linux user, although it is possible to run newer versions with reduced privileges, it is unlikely that many sites are doing so.
The announcement of the vulnerability came from ISS, CERT, and the Sendmail Consortium, saying that exploits were possible, but not in the wild. Within several days, Last Stage of Delirium, a Polish security site, published an exploit that would allegedly work only on Slackware Linux version 8 sendmail. Notes accompanying the exploit hinted that RedHat versions could also be exploited, but no examples were provided.
Even before the news of the exploit appeared, UNIX system administrators were rushing to find and patch all their sendmail servers. Finding sendmail servers can be done by scanning networks for servers listening on port 25/TCP, connecting to those servers, and collecting the banner that email servers send as an announcement. Vulnerability scanners, including the free Nessus tool, can find vulnerable versions by scanning a network. But sysadmins still can have a difficult time determining the patch level of any sendmail servers found.
The banner presented by sendmail servers gets part of its version information from the sendmail configuration file, and the reset from the program itself. Patching a sendmail server does not update the configuration file. Older versions of sendmail could also be patched, so just seeing an older version number in the banner doesn't tell a system administrator anything reliable about the patch level.
The sendmail configuration file itself created consternation for sysadmins. This configuration file is infamous for its complexity, and all the newer versions of sendmail use an automated method for creating it. But getting the ideal configuration can still be a matter of trial and error, and upgrading to the newest version of sendmail involved upgrading to a new configuration file as well.
At the end of March, Michael Zalewski found another potentially exploitable buffer overflow in sendmail. Although no exploit had been posted, sysadmins once again had to find and patch all their sendmail servers. One hopes that they kept track of those patched the first time around.
Both sendmail vulnerabilities required very long header lines in an attack. The LSD exploit sends an address in a header that begins with 278 characters, before more are added to adjust the placement of part of the attack code. The attack itself is contained in a single line that is almost 2048 bytes long. Both of these features should be blocked by SMTP AGs. I talked to several firewall vendors whose products include SMTP AGs (SecureComputing, Symantec, and WatchGuard), and all vendors claimed that there AGs blocked the LSD exploit. Networks protected by these AGs had a working defense against attacks from the Internet. Sendmail servers still needed to be patched, because these vulnerabilities could be used internally, or locally as an elevation of privilege attack. But the immediate risk had been greatly reduced by using the strongest firewall technology.
In mid March, Microsoft announced that a problem had been found in IIS 5. Using the WebDAV interface, a DLL called through IIS 5 was susceptible to a buffer overflow. To compound matters, the module, ntdll.dll, runs with Local System privilege, and can also be reached via other system software. Within days, several exploits for the WebDAV buffer overflow were posted.
This particular IIS exploit requires that a filename parameter passed as part of an HTTP request header be at least 64 kilobytes long. Such pathologically long filenames should be easy to spot--but only by AGs written specifically for protecting HTTP servers.
The fourth critical vulnerability in March involves the Windows Scripting Engine, used by Internet Explorer in all versions of Windows. By late March, no exploit had appeared, although this vulnerability could potentially be used for launching the next Melissa virus. None of the firewall vendors I talked to could tell me if they could defend against this new vulnerability.
The final vulnerability in March 2003 involved the Open Source software #snort#. Snort is highly rated Intrusion Detection software, used by many sites, and sometimes in a configuration where the sensing interface is outside of a firewall and the reporting network interface is connected to the internal network. The vulnerability, also announced by ISS, involved a buffer overflow in a snort module that handles RPC packets. A single, carefully crafted packet sent past the sniffer could compromise snort, which runs as root. In the configuration I described here, no firewall would help. In this case, system administrators had no recourse but to either install the patch, or disable the snort RPC module.
By early April 2004, none of these five vulnerabilities were being widely exploited. In three of the five cases, AG-based firewalls would protect internal networks from exploits based on these vulnerabilities--even though the details of exploits based on these vulnerabilities were previously unknown. You gain this defensive feature by using AGs, something that you don't get by using other firewall technologies.
It's your choice: speed or more rigorours firewall security.
New sendmail vulnerabilities announced in March: http://www.cert.org/advisories/CA-2003-07.html and http://www.cert.org/advisories/CA-2003-12.html
Microsoft Security Bulletin for the WebDAV vulnerability in IIS 5: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/ms03-007.asp; IE vulnerabilty in Windows Scripting Engine was MS03-008.
LSD Sendmail Proof of Concept code for pre-sendmail-8.12.8 on Linux: http://seclists.org/lists/bugtraq/2003/Mar/0044.html
A short report on other potential means of exploiting ntdll.dll: http://www.ngssoftware.com/papers/ms03-007-ntdll.pdf
Symantec response to WebDAV:
http://securityresponse.symantec.com/avcenter/security/Content/3.17.2003.html
My firewall search tool that can help you find firewall features: http://www.spirit.com/firewalls/