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

[tqbf () pobox com]

> > --- but they have increased vulnerability to problems in other IP stacks,
> > because they are allowing remote hosts to communicate directly with those
> > stacks.
> I disagree with this assumption.  Current SPF implementations do this.  It
> doesn't mean someone couldn't write a better one.

> > Packet filtering firewalls work by allowing *some* external network
> > traffic to reach the internal network.
> If you're still speaking of up to layer 3/4, it wouldn't be that hard to
> write a SPF to redo all that info.  SPFs that do NAT already do
> much of it.

> Most SPF implementations currently allow a lot of the original reply
> through.  This is appropriate for some protocols, and obviously
> not for others.  An SPF can be written to strip off as much as you like.

And so on, and so forth.

It will be difficult for us to discuss the tradeoffs between packet
filtering and proxying if we cannot agree on definitions. Your definition
of stateful filtering:

> Know what the difference between an AG and an SPF is?
> The AG allocates the socket from the OS.  The SPF allocates
> the connection from itself.  If one wants to write an SPF that
> answers the system calls that allocate sockets, you can have
> all the security you like at the application layer, and get the extra
> security available with a really well written SPF.  Anyone know how

... is very far removed from my definition, which is "a device which
filters packets". The basic concern I have with your argument at this
point is that much of what you suggest as an improvement for a stateful
filter would turn the machine into a proxy.

I understand that a stateful filter can reassemble fragments. However, by
my definition, as soon as the firewall collects and reassembles fragments,
and transmits the reassembled fragment, it has ceased "filtering" --- the
firewall did not allow any external traffic through, but rather
interpreted the packets itself and sent the internal hosts it's
interpretation. This is a defining difference between a packet filter
and a proxy.

Your concern with application gateways is that they have increased
vulnerability to attacks against their own IP stack. This is a valid
point. However, you must keep in mind that this vulnerability is a result
of the fact that the A-G needs more code to function than a typical
stateful filter. As you add more code to a stateful filter, to make it
approximate normal IP stacks, strip off protocol data, or reassemble
fragments, you make the filter more like a proxy, with all the attendant
risks. 

Now, my concern with a firewall implementation doesn't linger too long on
the security of the firewall's own IP stack --- not because this isn't an
issue, but because it's a simplifying assumption for my research that a
given firewall is implemented carefully enough so that it isn't vulnerable
to direct attacks. If the security of the firewall machine itself is more
of a concern to you than the overall security of the network with the
firewall installed on it, you may have a valid reason to distrust
application gateways, as opposed to simple stateful filters. Personally, I
think the firewall's effectiveness at it's job is more important.

Your argument continues with some poor assumptions, which I'll point out
but try not to linger on:

> So... if there was some IP-layer root compromise was discovered, the
> machine running the AG would get compromised.  For a bad

No. If the A-G ran on a vulnerable IP stack, it would be compromised. If
the A-G is implemented on a special-purpose stack, it would not be
vulnerable to anything but an attack specifically designed to compromise
the A-G stack. From Bellovin: "all software is buggy". The same risk
applies (perhaps to a lesser degree) to a stateful filter, which can just
as easily breed remotely exploitable bugs.

The issue here is that a correctly implemented A-G (a hypothetical beast
we're considering for the purpose of this argument) will have a hardened
IP stack. Is there a risk that a hardened IP stack can be vulnerable to
attack? Sure. Does that risk outweigh the risk that a packet filter taking
it's place could allow traffic through that would compromise an
end-system? Which is more likely to have bugs, a hardened IP stack or a
general-purpose end-system stack? More importantly, what is the primary
design goal of a firewall? I'd assert that it's to shield end-systems from
their own vulnerabilities.

> An SPF doesn't have to know how to deal with every IP stack it protects.

It absolutely does. Remember, a defining difference between filtering and
proxying is that in filtering, original packets are forwarded to internal
hosts. This forwarding is "guarded" by a filtering engine which attempts
to make determinations about the implications of each packet. If the
filtering engine does not know how an end-system will react to a given
packet, it has a reduced capability to make conclusions about the security
of the packet. 

There are two different outcomes of this problem: either the filter will,
as a precaution, block any ambiguous traffic it sees, thus damaging
connectivity by filtering legitimate traffic, or it will allow ambiguous
traffic to be forwarded, thus damaging the security of the network by
allowing packets with unknown implications to be forwarded.

> This is a result of current SPF vendors doing a sloppy job.   If you
> write a SPF filter to do the same job as a good app proxy, it will

An SPF filter that does "the same job" as a proxy is a proxy. There is no
way to do the same job as a proxy without becoming an endpoint in network
communication (in other words, generating your own traffic to send). 

> With a bad SPF, sure.   Again, I claim that SPFs can do as much, or more,
> than "real" IP stacks.  

I don't understand the logic behind this assertion. By definition, a
packet filter does less than an IP stack. IP stacks have free rein to do
whatever they want with traffic. What can an SPF, without violating the
design concept of "packet filter", that an application gateway cannot
(without violating the design concept of "proxy")?

> Heck, it would be pretty easy to pick a random number
> of bytes out of the datastream, and buffer outside packets until you had
> that many, and then make a new packet to send to the inside machine.
> Somewhat similar to how an AG behaves.

In some protocols, this behavior is identical to proxying; that is, you no
longer have a packet filter when you do this. In others, TCP being a
notable example, buffering packets (if you can do it at all) does not
approximate the behavior of a proxy, which maintains independant
synchronization with two endpoints.

> > reassembly at offset=(n != 0)" bug, which caused NT to reassemble invalid
> > fragment streams. No A-G firewall was vulnerable to this attack, because
> > A-G's don't pass fragments.

> But any AG running on NT with the MS stack was?

No, even A-G's running on NT did not create this vulnerability. The reason
this NT fragmentation bug was a serious security problem was because it
allowed fragments to be forwarded through firewalls without having their
security implications properly evaluated. Even on NT, an application
gateway doesn't forward fragments. While it is possible to send an invalid
stream of fragments to an NT A-G and have them reassembled, this does not
impact the security of the network. 

> I imagine the IDS vendors will have to start assembling fragments,
> and checking for valid frag pointers.  Are you implying that they
> can't, won't, or it's too hard?

Yes. See http://www.secnet.com/ids for a 60+ page technical report that
explains why we think it is "too hard" for a sniffer-based IDS to perform
tasks like fragmentation reassembly accurately. Key point: there are
pathological fragmentation streams which will be reassembled in two
different ways by two different stacks. Again, exploitable inconsistancy.

> > Issues of code integration have nothing to do with the security of
> > firewall design approaches.
>
> Then why does it matter if the security is in two seperate pieces..
> IP stack and AG code, versus one piece, well written SPF?

Because you are comparing apples to oranges, and confusing the comparison
by putting it the context of an implementation question, which has little
to do with this argument.

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