Re: Firewall-Wizards Digest V1 #197

["Steven M. Bellovin" <smb () research att com>]

In message <19980928135658.A735 () i-way co uk>, Steve George writes:
> --BXVAT5kNtrzKuDFl
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: quoted-printable
>
> Hi,
>
> Since a proxies are normally considered to act the application level there =
> is no particular reason why theu should not understand more about the proto=
> col that they are proxying.  With connectionless protocols such as SMTP thi=
> s is quite straightforward since you can implement the set of commands whic=
> h you consider safe and then forward the stuff to the other end, hence FWTK=
> doesn't do some of the SMTP commands.   However, with connection orientate=
> d proxies such as telnet you have to implement all of the protocol as you d=
> on't know what the user will do with it.  However, it seems to me that in e=
> ssense the problem is with the implementation of the thing at the other end=
> of your proxy not the fact that you can telnet to it rather than use a bro=
> wser.

Application proxies are probably the safest for the inside net.  Unless
implemented very carefully, they are the greatest danger to the firewall itself.
And I fear that we are heading in that direction.

Firewalls work because they don't run code.  That is, they don't run the
dozens of services that most out-of-the-box computers run -- services
that, even if they have adequate access controls, are likely to be buggy.
When we start adding dozens of application proxies to our firewalls, we
are exposing them to the same risks.  Why, to cite just one example, do
you think that firewalls aren't vulnerable to buffer overflow attacks?

I'll be so crude as to cite myself and refer people to Section 4.8 of
my book, the safety analysis.  It explains -- and we actually went through
this in far more detail ourselves -- exactly why we felt that every
application running on our firewall was safe.  Can you go through a
similar exercise, for each oddball application you want to proxy?  (Fred
Avolio alluded to this problem when he described the original http proxy,
which was just a wart on the side of an already-large Web server.)

Yes, the problem is with the implementation.  That's usually the case for
security holes.  85% of all the CERT advisories ever issued describe
problems that can't be fixed with cryptography; most are implementation
bugs.

Marcus Ranum understands this quite well; see his ultimate firewall
description, at http://www.clark.net/pub/mjr/pubs/a1fwall/index.htm.
Also see my 10BaseT firewall design (and my secure firewall), at
http://www.research.att.com/~smb/talks/net-inet-sec/sld078.htm.