Re: Proxy 2.0 secure? (AG vs. SPF)

[tqbf () pobox com]

Bellovin's fundamental theory of firewalls is that general-purpose
computers have too many bugs to be run exposed to a network (based on the
assumption that all programs are buggy). The purpose of a firewall is to
shield these machines, reducing the exposure of entire programs to the
network. The basic point: "if you do not run a program, it does not matter
if it is buggy or not". The less a host interacts with the network, the
more secure it is. Since all software is buggy, the less software involved
in a program, the more secure it is.

> AGs are completely vulnerable to problems in the lower layers
> of IP stacks.  

No. A-G's are completely vulnerable to problems in their own IP stack, but
completely invulnerable to problems in other IP stacks. Packet filters, on
the other hand, have reduced vulnerability to direct attacks on their own
IP stack (because they have less of a stack, see Bellovin's principle) 
--- but they have increased vulnerability to problems in other IP stacks,
because they are allowing remote hosts to communicate directly with those
stacks. 

It is valid to assume that the IP stacks of end-systems are less secure
than the IP stack of the firewall. If nothing else supports this
assertion, we assume that there are (or will potentially be) multiple
different IP stacks on the network, each of which has it's own unique
bugs. One stack is more secure than many stacks; all stacks have bugs,
general-purpose stacks have more bugs than hardened stacks, and it is
easier to manage the security of one centralized piece of code (the
firewall IP stack) than the security of distinct programs from multiple
vendors. 

A well-designed proxy server does not allow *any* external network traffic
to reach the internal network. Instead, it completes all interactions
between the inside and the outside, relying on the internal machines only
to provide the actual data needed for those connections. Internal machines
only receive traffic that originated from the proxy server, and we can
thus assume that, at least at the low level of TCP/IP, that traffic is
safe.

Packet filtering firewalls work by allowing *some* external network
traffic to reach the internal network. Security is improved by interposing
a packet filtering engine that attempts to make a determination about the
security of each packet. Stateful packet filters simply support this
reasoning by considering each packet within the context of a network
traffic stream (a TCP connection, for example). Internal machines only
receive traffic from the outside world, and we cannot assume that any of
that traffic is safe. 

The choice between application-gateway and packet-filtering firewalls
comes down to this simple issue: we can decrease the exposure of
end-system IP stacks by increasing the exposure of the firewall IP stack. 
The reason that application-gateway firewalls are more secure than packet
filters is that it is easier to maintain the security of one stack
(especially when it's well-understood that it's pivotal to the security of
a whole network, and especially when it is specifically designed for
security) than it is to maintain the security of many stacks.  

> someone's IP stack.  You'd be more fortunate than most of it's
> not the original stack that came with the host OS, and was written
> byt someone who knew what they were doing.

This seems to be the crux of your argument. It isn't a valid argument, but
I can see the logic. There are application gateway firewalls that rely
entirely on general-purpose vendor IP stacks. The TIS firewall toolkit is
a good example. Naturally, a firewall that rides a standard stack is
vulnerable to attacks against that stack. Indeed, it is probably true that
an application-gateway firewall riding on, for instance, the Solaris
TCP/IP stack is LESS secure (considered as a whole, implications to the
internal network included) than a stateful packet filter.

Of course, the response to this point is "So what?". I can design a
stateful packet filter that won't perform stateful inspection of IP
fragments, instead passing them directly through and assuming them to be
safe. Does this mean stateful firewalls are insecure? Of course not. It
simply means that it is possible to design a bad stateful filter, which is
an obvious point.

While it is true that, as a practical matter, we must consider the actual
implementations of A-G and filter firewalls when discussing their
security, and, in light of that consideration, the stateful filter market
may very well have a better track record than the A-G market (I doubt it
does, but it's possible), the point I am making is that, by design, A-G is
the more secure approach.

In other words, if you compared the best A-G to the best stateful filter,
the A-G would be conclusively more secure.

[ re: SPF == Performance Hack ]

> While I don't claim to have as much insite into the intentions
> of SPF developers as you do, I do know that a good SPF

It doesn't take insight. If security was the only issue, the right
approach to firewall design would simply be "design a maximally secure IP
stack". The less external traffic that is allowed to reach the internal
network, the better. A-G firewalls allow no external traffic to reach the
internal network. Zero is better than some, even if "some" is very small
and sanitized.

Security isn't the only issue. Performance is a major issue. The fact is
that it takes more code to perform high-level proxying than it does to
evaluate and filter network traffic. Stateful filters are faster than
proxies (right now, significantly so); this speed comes at the expense of
a design goal (minimize exposure to external traffic). 

> [a SPF firewall] implementation could stop many more attacks than an AG
> could. Take all of the screwing-with-the-frag-pointers attacks

Hardened IP stacks aren't necessarilly vulnerable (indeed, it is highly
unlikely that they are or would be vulnerable) to the fragmentation games
used by the Teardrop attack. A real A-G built on a hardened IP stack is
easily capable of blocking fragmentation attacks against itself, and the
challenge of writing software that resists fragmentation attacks against
one carefully guarded host is much easier than the challenge of protecting
multiple weak hosts. 

On the other hand, a stateful filter is vulnerable to fragmentation
attacks designed to confuse traffic analysis as to the "state" of a
reassembling fragmented packet. The stateful filter must either block all
fragments until the complete packet arrives (in which case the firewall is
actually proxying fragments), or else allow fragments to pass without
knowing what future fragments will arrive. If an attacker can find an
exploitable inconsistancy between a vendor IP stack on the internal
network and the stateful filter, she can slip arbitrary fragments through
the filter.

We've already seen one example of this attack --- the Windows NT "start
reassembly at offset=(n != 0)" bug, which caused NT to reassemble invalid
fragment streams. From owner-firewall-wizards  Tue Jun 30 08:47:43 1998
Received: (from lists@localhost)
        by nfr.net (8.8.8/8.8.8) id IAA00792
        for firewall-wizards-outgoing; Tue, 30 Jun 1998 08:37:31 -0500 (CDT)
Received: (from fwiz@localhost)
        by nfr.net (8.8.8/8.8.8) id IAA00779
        for firewall-wizards () nfr net; Tue, 30 Jun 1998 08:37:28 -0500 (CDT)
Received: from copper.cmp.com (copper.cmp.com [192.155.65.19])
        by nfr.net (8.8.8/8.8.8) with ESMTP id WAA25409
        for <firewall-wizards () nfr net>; Mon, 29 Jun 1998 22:26:09 -0500 (CDT)
Received: from NotesSMTP-01.cmp.com (gw57-25.cmp.com [192.155.57.25])
        by copper.cmp.com (8.8.8/8.8.8) with SMTP id XAA11233;
        Mon, 29 Jun 1998 23:29:12 -0400 (EDT)
Received: by NotesSMTP-01.cmp.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 85256633.00132412 ; Mon, 29 Jun 1998 
23:29:04 -0400
X-Lotus-FromDomain: CMPNOTES
From: "David Newman" <dnewman () cmp com>
To: tqbf () pobox com, firewall-wizards () nfr net
Message-ID: <85256633.00112303.00 () NotesSMTP-01 cmp com>
Date: Mon, 29 Jun 1998 23:21:34 -0400
Subject: Re: Proxy 2.0 secure?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-firewall-wizards () nfr net
Precedence: bulk
Reply-To: "David Newman" <dnewman () cmp com>

> It would be silly to write an article comparing the security of firewalls
> by considering the many ways in which they can be misconfigured.
> Obviously, the Data Communications article is not referring to security
> holes brought on by misconfiguration --- they had the vendors configure
> the boxes for the test. Clearly, the security problems we are discussing
> here are design and implementation flaws, not configuration and management
> mistakes.

> So, I'll restate my point: network scanners are excellent tools for
> verifying the configuration of a firewall. The review of firewalls we're
> discussing is not about proper configuration. It's about whether software
> packages from various vendors are "secure",

Thomas, at this point I have to think you either are willfully distorting
the test's conclusions or you really missed the point.

The article made clear that we did not in any way certify products as
"secure," whatever that means. Our tests evaluated only whether properly
configured products would behave as they should--in other words, that the
code itself had no vulnerabilities to a known set of attacks. We also
stated that vulnerabilities due to misconfiguration and new attacks are
both very real problems, but beyond the scope of our test. I agree that
scanners and IDS products are a good way of evaluating device configuration
(and I'm pleased to see you think IDS products are good for something ;-)

Regards
David Newman
Data Communications magazine




No A-G firewall was vulnerable to this attack, because
A-G's don't pass fragments. This attack was a recent discovery, and I have
seen no literature (our IDS paper excluded) that explored the
ramifications of this type of attack.

In my opinion, supported by months of experience expirimenting with
precisely this issue (in the context of intrusion detection), it is
unwise to assume that the exact same underlying problem won't resurface in
TCP or stateful UDP traffic. A-G's won't be vulnerable, but the vulnerable
stateful filters will be, and in the worst possible way; attackers will be
able to bypass the firewall as if it wasn't even there. Is this a risk you
want to take with your network? More power to you.

> It's a matter of how you like to do your firewall software.  SPFs could
> do it all in one piece.  AGs do it in at least two pieces, and if the
> AG comes with it's own IP stack, then the vendor has as much

Issues of code integration have nothing to do with the security of
firewall design approaches. An application gateway firewall can consist
entirely of a special-purpose kernel which runs only a hardened IP stack
(and attendant proxies), in which case the firewall is "all one piece".
Stateful filters can be implemented as multiple pieces. This is an
implementation issue.

-----------------------------------------------------------------------------
Thomas H. Ptacek                           SNI Labs, Network Associates, Inc.
-----------------------------------------------------------------------------
http://www.pobox.com/~tqbf       "If you're so special, why aren't you dead?"

DISCLAIMER:

I work for Network Associates. Network Associates is a vendor of an A-G
firewall called Gauntlet. I have nothing to do with Gauntlet --- I work at
NAI because they bought my company, a security scanner vendor. However, if
you're paranoid, you can assume that all this talk is motivated by my
desire to increase the value of my stock options.

I do not speak for NAI.