RE: Leader in firewall product

["LeGrow, Matt" <Matt_LeGrow () NAI com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> -----Original Message-----
> From: Marcus J. Ranum [mailto:mjr () nfr net]
> Sent: Monday, September 18, 2000 1:19 PM
> To: jseymour () LinxNet com; firewall-wizards () nfr net
> Subject: Re: [fw-wiz] Leader in firewall product

Pardon me for chiming in on this thread, but I think I have read just
about enough random slagging of Gauntlet for the day without speaking
up at least once :-)

> The design was conservative and (in my opinion) pretty decent. But
> there were a few implementation flaws and conceptual flaws, as
> well. We added proxy transparency in 3.0, and at that point I felt
> that the security of the system took a big leap downward - when
> you've got a firewall that's basically transparent to the end user,
> it's also basically transparent to a trojan horse.   

The problem you're talking about has little to do with transparency,
rather with the overall security of application-level proxies
themselves.  Tunnelling protocols over protocols is not a new thing,
but the degree and extent to which application protocols, especially
HTTP, are used for this purpose *is*.  If I am the programmer of said
horsie, I can probably count on outbound HTTP, FTP and possibly
telnet being enabled.  I don't care if I have to connect directly to
the proxy or not, because its trivial to take the steps to do so. 
And if my horsie is smart, it will attempt to do so.  And unless the
proxy parses every line of HTTP code and is looking for signatures
specific to my horsie, I can count on a clean path.  

This is a problem that Gauntlet, as well as everyone else in our
niche, has had to struggle with in their own way.  I think we've made
good progress recently with this in our product in keeping with this
trend (such as RealAudio and DCOM over HTTP), but then again, I am
not the most unbiased source of such a barometric reading :-)

> There were two components of the firewall proxies that desperately
> needed a code review and never got one: the http proxy and the
> X-Window proxy. They did a lot of complex string-pounding and would
> have been a great breeding ground of buffer overruns, etc. In
> those days, things like stack guard weren't available, and I
> always wanted to figure out a way to harden the processes so they
> couldn't be buffer overrun'd but never had time. :( 

There were
> a lot of places in Gauntlet that could have used considerable
> shoring up, but we were always overloaded and never had time to
> get back to them.

This is a complaint that you could probably quote from any software
engineer working on any commercial product at any given time.  Just
think: if we were all Theo De Raadt, then we could have the luxury of
answering that the problem was fixed two years ago in OpenBSD release
X.5 and why the hell hasn't anyone else caught on :-)

> mjr.
> -----
> Marcus J. Ranum
> Chief Technology Officer, Network Flight Recorder, Inc.
> Work:                  http://www.nfr.net
> Personal:              http://www.ranum.com
>
>
> _______________________________________________
> Firewall-wizards mailing list
> Firewall-wizards () nfr net
> http://www.nfr.net/mailman/listinfo/firewall-wizards


Matt LeGrow
Network Associates, Inc.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Note : Opinions expressed herein are most certainly NOT that of my
employer :-)

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1
Comment: Crypto Provided by Network Associates <http://www.nai.com>

iQA/AwUBOcaZCvbW52zw8/NBEQK0TgCgnxkm22z01Npddcs7FjpmAirrzt8AnAwa
KTSNqvDrd2XovY31DenRPYls
=6JnX
-----END PGP SIGNATURE-----

_______________________________________________
Firewall-wizards mailing list
Firewall-wizards () nfr net
http://www.nfr.net/mailman/listinfo/firewall-wizards