Great Circle Associates Firewalls
(October 1997)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: sex, lies, and firewall code
From: "Ryan Russell"<ryanr @ sybase . com>
Date: Sun, 26 Oct 1997 18:25:02 -0800
To: proberts @ clark . net
Cc: firewalls @ GreatCircle . COM


It's about the same as if some of the generic
proxies (for example, SOCKS) passed  OOB
flags and data, not knowing if the application
needs them (Telnet, FTP) or not.  I'm guessing
that there aren't any well-done application
specific proxies for whichever MS protocols
live on that port?  If there were, would they have
left off the OOB flag?  Probably, but you can't
guarantee that.

In your favor, SPFs probably have to explictly
strip extra stuff out, while AGs probably have
to explicitly add that on.  This will be good or
bad depending on whether the new protocol
you want to pass breaks because the OOB
got stripped, or works because it was needed
and it got passed automatically.  I guess I'd rather
have things default off, and have it break, so that I'm now
aware that I have to click the "pass OOB" checkbox
in the GUI.  Hopefully either one's SPF or AG will
be flexible enough so that one can adjust those things
as needed.  For the Checkpoint folks on the list, I'd
like to see that as a default.

To answer your question, Firewall-1 can pass or
not pass OOB on a per-app basis, so as to
protect from that bug, but still let FTP and Telnet work.

BTW, your point (as stated) in the note I was
replying to was not "Firewall-1 didn't protect from
it automatically" (which would be correct) it was "SPFs
CAN'T filter that stuff, because..." which is wrong.

                    Ryan





proberts @
 clark .
 net on 10/26/97 09:17:19 AM

To:   Ryan Russell/SYBASE
cc:   firewalls @
 GreatCircle .
 COM
Subject:  Re: sex, lies, and firewall code




On Sun, 26 Oct 1997, Ryan Russell wrote:
> They can can and do protect from the OOB bug.  Now, you might
> have a legitimate complaint in that Checkpoint didn't do that until
> after the attack was discovered.
That was the main point.  It's forwarding packets, or the initial
vulnerability wouldn't have been there.  I'm still not convinced that the
'protection' offered for the current bug covers some other rumored
problems with the same class of attack with other OOB packets, but until I
get lots of free time to generate raw packets, I'll leave that alone.
The initial Checkpoint reaction was "Block all OOB packets", obviously
breaking FTP and Telnet functionality.  That tells me that there is a
flaw in the base technology that allows transport layer attacks.  Granted
it was fixed, but who's to say that there aren't more transport layer
holes out there?  Will you have to wait for a fix to each one?  That's a
problem with packet filters that isn't there in hardened bastion hosts
running proxies.  Even if the gateway is vulnerable, the hosts behind it
aren't.  Since we tend to upgrade internal machine much more often than
gateways, I find that a major issue.  What if the OOB attack's signature
was the same as a legitimate packet for a different OS, how would that be
handled in Checkpoint's world?
Paul
---------------------------------------------------------------------------
--
Paul D. Robertson      "My statements in this message are personal opinions
proberts @
 clark .
 net      which may have no basis whatsoever in fact."

PSB#9280







Follow-Ups:
Indexed By Date Previous: Re: Algorithmically derived passwords
From: "H. Morrow Long" <morrow . long @ yale . edu>
Next: Re: sex, lies, and firewall code
From: "Paul D. Robertson" <proberts @ clark . net>
Indexed By Thread Previous: Re: sex, lies, and firewall code
From: Anton J Aylward <anton @ Toronto . com>
Next: Re: sex, lies, and firewall code
From: "Paul D. Robertson" <proberts @ clark . net>

Google
 
Search Internet Search www.greatcircle.com