Multiple vendors' TCP/IP implementation allow packets to bypass firewalls - VU#464113

Thu Oct 24 00:33:36 UTC 2002

-----BEGIN PGP SIGNED MESSAGE-----

Hello NANOGers,

I am sending this to you for your evaluation and possible feedback.

The CERT/CC has reviewed a report describing a method that
significantly improves an attacker's chances of successfully
circumventing a firewall.

In a mail thread taking place on the Bugtraq mailing list, research is
described which may allow an attacker to circumvent a firewall.

- - Paper: <http://online.securityfocus.com/archive/1/296122/2002-10-19/2002-10-25/2>
- - Thread: <http://online.securityfocus.com/archive/1/296558/2002-10-19/2002-10-25/1>

In this message, we begin by presenting some background information
for those who are unfamiliar with TCP/IP connection semantics. We then
go into specifics regarding how an attacker can circumvent various
firewalls by using specially crafted packets. Next, we examine the
various impacts resulting from exploitation of this
vulnerability. Finally, we present a sample mitigation strategy that
will enable you to better protect resources located behind firewalls.

- ---Background on TCP/IP Connection Semantics---

As many of you may know, to establish a TCP connection, the client and
server must participate in a three-way handshake.  The client system
begins by sending a SYN message to the server. The server then
acknowledges the SYN message by sending SYN-ACK message to the
client. The client then finishes establishing the connection by
responding with an ACK message. The connection between the client and
the server is then open, and the service-specific data can be
exchanged between the client and the server.

A firewall can be used to manage the connection setup and subsequent
traffic flow between the client and server. In general, firewalls are
of two types: packet-filtering firewalls, and application-level
firewalls. Packet filters look at the source, destination, types, and
options associated with the packet, while an application level
firewall can "look inside" the packet to examine application-specific
attributes. This document is concerned primarily with packet-filtering
firewalls (which are much more common), including routers acting as
packet filters.

Section 3.4 (Establishing a connection) of RFC793 (Transmission
Control Protocol) describes the three-way handshake as the standard
procedure used to establish a connection. Firewalls will typically not
allow this process between hosts that are not permitted to communicate
with each other. For example, if an attacker sends a packet (with the
SYN bit set) to a victim server, the firewall will not relay this
packet to the victim because the firewall's rules only allow packets
with the SYN bit set to originate from certain hosts. As a result, the
three-way handshake will not be completed, and the attacker will not
be able to establish a connection with a host behind the
firewall. This method of filtering SYN packets is typically the method
used by packet-filtering firewalls to prevent certain hosts from
"getting past the firewall."

- ---How the Attacker Can Bypasses the Firewall---

An attacker is free to set whatever flags he chooses to set on any
packet. RFC973 defines the meaning of certain bits, but does not
address scenarios in which odd bit combinations are encountered. The
method in which the packet is handled is left up to the TCP
implementer. As you might imagine, different implementations handle
these "odd bit combinations" in a variety of ways. Some
implementations are more liberal in what they accept, and choose to
treat ANY packet with the SYN bit set (regardless of what other bits
are set or unset) as the opening in the three-way handshake. Some
implementations are more conservative, and drop packets with
unexpected combinations of flags. In the case of a liberal
packet-filtering firewall, it may allow a packet to pass if, for
example, the FIN bit is set, even if the SYN bit is set.

This ambiguity results in a vulnerability in certain
conditions. Suppose you have a "liberal" firewall which passes packets
if the FIN bit is set, regardless of the value of the SYN
bit. Furthermore, suppose you have a "liberal" host that accepts a SYN
bit as the opening of the three-way handshake even if the FIN bit is
set . An intruder can now send a packet with the SYN and FIN bits set,
and establish a connection with the host behind the firewall in
violation of the expected behavior.

In effect, the firewall says,"I'll let this packet pass because its a
FIN packet," but the host says, "I'm going to establish a connection
because its a SYN packet." In reality, the meaning of a packet with
the SYN and FIN bits set is undefined.

Research has shown that multiple TCP implementations will allow a TCP
session to be established with hosts located behind the firewall by
setting certain combinations of bits in an initial packet. This
research indicates the following TCP implementations are "liberal" in
what they accept.

Linux (2.4.19 Kernel)
Solaris 5.8
FreeBSD 4.5
Windows NT 4.0

The researchers go on to indicate that, "Other OSes than those tested
above are expected to behave in a similar manner after obtaining such
a discouraging result..."

Additionally, it appears that many firewalls are unexpectedly liberal
in passing packets. We are investigating both aspects of this systemic
vulnerability.

- ---Impact---

The impact of this vulnerability is that an attacker may be able to
establish connections with hosts behind firewalls in violation of
implied security policies. As a result, an attacker can send data to
hosts and services that he ordinarily cannot reach by exploiting this
vulnerability.

As an example, consider the following scenario. You want your internal
name server to be able to initiate zone transfers with certain hosts
external to your network. Depending on what firewall implementation
you are using, you might have a rule that looks similar to the
following.

iptables -A FORWARD -p tcp -s 10.10.10.1/32 --dport 53 -j ACCEPT

And, you may have a rule that permits the reply, that looks like this:

iptables -a FORWARD -p tcp --sport 53 -d 10.10.10.1/32 ! --syn ACCEPT

Because of the ambiguous nature of TCP semantics, *anyone* can attempt
*inbound* TCP connections to *any* port on 10.10.10.1 using SYN,RST
packets sourced from port 53. Hopefully you do not have other services
running on this machine, because now the attacker can connect to any
listening services on the host in question.

You might also imagine that an intruder could leverage this flaw to
exploit a vulnerability in passive software listening promiscuously on
the inside of the firewall (e.g. vulnerability in tcpdump
<http://www.kb.cert.org/vuls/id/776781> or some similar
vulnerability).

The specific kinds of packets that may bypass a firewall are highly
dependent on the implementation of the firewall.

- ---Mitigation Strategies---

Create filtering rules designed to drop and/or reject packets with
certain combinations of bits set in initial synchronization
packets. Paul Starzetz <paul at starzetz.de> (the author of the research)
proposes using the following mitigation strategy for systems making
use of iptables. Please note that this particular ruleset will only
protect you from an attacks using the combination of the SYN & FIN
bits.

iptables -A INPUT -p tcp -d HOST/MASK --tcp-flags SYN,FIN SYN,FIN -j LOG -m limit --limit 10/m --log-level "LOGLEVEL" --log-prefix="bogus packet"

iptables -A INPUT -p tcp -d HOST/MASK --tcp-flags SYN,FIN SYN,FIN -j DROP

Please make sure to include VU#464113 in any feedback you send to us
at cert at cert.org. This unique, random number will help us track
correspondence and coordinate our activities.

As always, thanks.

Regards,
Ian

Ian Finlay
Internet Systems Security Analyst - CERT/CC Operations
Networked Systems Survivability Program
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
CERT (R) Coordination Center             Email: cert at cert.org
Software Engineering Institute           WWW: http://www.cert.org
Carnegie Mellon University               Hotline: +1-412-268-7090
Pittsburgh, PA  USA  15213-3890          FAX: +1-412-268-6989
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv

iQCVAwUBPbdDDmjtSoHZUTs5AQHPsAP/T8SR/K8OZ4IT5neq3kxMMF5JFPLrKdmq
DgmDZD1QFDvNHd6P9WOZsI8ike70r7y/ACX5Idlt2LIk3IKO48pcHIQ2F0fWl3Z5
gxt03egJLhEtdIwEMz64Jt9HvKEz2rhZiXI8b3cL4aS7PzEfMxYGiOFUJJbmox3M
dvhwkv4xANY=
=lFt7
-----END PGP SIGNATURE-----