Great Circle Associates Firewalls
(June 1997)
 

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

Subject: Re: Stateful Packet Filters vs. Proxies
From: "Paul D. Robertson" <proberts @ clark . net>
Date: Tue, 10 Jun 1997 14:07:35 -0400 (EDT)
To: Ryan Russell/SYBASE <Ryan . Russell @ sybase . com>
Cc: firewalls @ greatcircle . com
In-reply-to: <199706101652 . JAA22951 @ notesgw2 . sybase . com>

On 10 Jun 1997, Ryan Russell/SYBASE wrote:

> I think the attack you are speaking of is
> a newer one than the one I've heard of
> as being called "Son of OOB"  which just
> changes the pointer to the OOB data by one.
> I have heard rumor of the one you mention,
> but haven't seen any exploit code yet.
> It would probably end up being called
> "The Bride of Son of OOB" or some such.

When things settle here, I'll try to follow up on it, though my time
becomes more scarce for "play" these days :(

> I see your point about the difference between
> fred and the URG flag.  My assumption about 
> proxy behavior was that a truly generic proxy
> would have to reproduce the OOB flag
> and data, not knowing of the protocol needs
> it or not.  Perhaps that's a really bad assumption.

In a proxy situation, the client connection happens to the proxy, which
talks the application protocol.  The proxy itself opens an independent
connection to the target host, and doesn't relay anything below the
application layer (generic case).  So, an URG flag from a client machine
(send ayt, for example with telnet) happens to the proxy, not to the
target host.  the proxy would do its own send ayt to the server, therefore
protecting the client from any response other than its own, and likewise
the server from any response other than its own.  That's why adding proxy
gateways tend to need application specific changes to the client end
(note, application layer proxies, not circuit level ones like SOCKS).   

> In my mind, not passing all parts of the protocol
> (without knowing specifically that you don't want it)
> would be a broken proxy. So, something like Gauntlet's 
> plug-gw will break telnet if you move it to a different 
> port other than 23? 

Plug-gw isn't a good example of a proxy, because it doesn't know about the
applcation layer.  telnet-gw would be a good example of a proxy.  There is
a difference between passing application layer data, and trasport layer
data.  In the case of an application layer gateway, it has its own
transport layer connection to both the client and the server, and
therefore, only its transport layer must be bug-free, not those of either
end of the connection.  A true application layer gateway (plug-gw isn't
one, it's a generic plugboard at the transport layer) knows the
application protocol, and passes everything which it likes.  Passing
things it doesn't know about defeats the purpose of having the gateway.
If "DEBUG" isn't something it needs to know about for SMTP, for instance,
it shouldn't pass it as a command.  The default stance is everything is
denied except that which is expressly permitted.  

> Does anyone know if the MUDs 
> etc.. that use telnet for clients use OOB flags and 
> such like real telnet does?  Do they work across a 
> plug-gw?
> 

They work through telnet-gw, and for the most part, probably work through
plug-gw as well.  

> FYI, SPFs will not pass TCP packets through with
> bad or out-of-order sequence numbers, so if that is key to
> the attack, then it wouldn't work.  

In that case, if you're not using a static route end-to-end, you'll miss
out-of-order packets that the stack would normally re-assemble.  That
would make SPFs functionally deficient for sites connecting through
multiple route networks.  I'd guess that most SPFs allow a range of
sequence numbers in, otherwise they'd spend a lot of time on support calls
about poor TCP performance. 

Again, the fact that the attack can be initiated by a compromised server
in response to a valid conversation makes sequence number prediction, or
invalid sequence number acceptance unnecessary, however it makes blind attacks
a great deal more difficult.

> > But,to conceed your point, If proxys do, in general, 
> strip some TCP options on the way through, then
> yes, allowing connections through a SPF to port
> 139 would allow the MS box to crash, and a proxy
> with the behavior your describe would not.

It's not a case of stripping, as much as it's a case of since the proxy
opens its own connection, only it needs transport level security.  The
window options and such negotiated by the client are negotiated to the
proxy only.  The proxy negotiates its own TCP layer connection with the
server. 

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


Indexed By Date Previous: Eagle NT questions
From: Stephen Holden <sholden @ digitalglobe . com>
Next: Re: Stateful Packet Filters vs. Proxies
From: proff @ suburbia . net
Indexed By Thread Previous: Re: Stateful Packet Filters vs. Proxies
From: Darren Reed <avalon @ coombs . anu . edu . au>
Next: Re: Stateful Packet Filters vs. Proxies
From: Ryan Russell/SYBASE <Ryan . Russell @ sybase . com>

Google
 
Search Internet Search www.greatcircle.com