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.
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 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? 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?
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.
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.
Ryan
---------- Previous Message ----------
To: Ryan.Russell
cc: firewalls
From: proberts @
clark .
net ("Paul D. Robertson") @ smtp
Date: 06/10/97 12:16:15 AM
Subject: Re: Stateful Packet Filters vs. Proxies
On 9 Jun 1997, Ryan Russell/SYBASE wrote:
> Just to clear up some of your misconceptions:
>
> The son of OOB attack is application specific,
> effecting only the Microsoft DNS server and the
> Microsoft Service at port 139 (which I think is the
> NetBIOS port, not sure.) It does not effect the
> TCP driver in general.
It was my understanding that the invalid TCP window size advertisment was
a general TCP flaw in the MS stack. The variant I'd heard of used the
URG flag to bypass the sequence number checking with a packet that set
the window size to an invalid number. For that, no packets would reach the
application layer at all.
I'll have to hack up some code and test it, and double check my sources.
> Think of it this way.. Say I discover that if I throw the
> word "fred" into the datastream of an HTTP connection
> Netscape will delete your harddrive. You're telling me
> that there are proxies out there that automatically
> filter out the word fred? Before I announce the attack?
No, I'm telling you that an application layer gateway doesn't pass TCP
options into the internal network. I specifically said lower layer
protocols, if you continue to want to misrepresent that as an application
layer problem, that's up to you. I'll say it one more time, more
clearly, just in case you really missed it:
An application layer gateway creates its own TCP connections, and doesn't
pass low level transport problems to the clients behind it. Since the
application proxy controls its own connections into the protected
network, and external transport layer packets don't go any further than
its external interface this makes this a non-issue for clients
behind application layer gateways. Only the gateway need be immune to
invalid TCP window sizes (without sequence number validation if what I'm
told is true, though in the case of a hostile, or compromised server,
this doesn't make much difference). Note this is TCP transport layer,
*not* a higher level application transport layer (Eg. HTTP).
If you're relaying the connection, then the clients are vulnerable at the
relay level. If you're not, then only you are vulnerable. Even if I
make the assumption that the information I was given is incorrect, and
the specific exploit isn't as I've been lead to believe, it is still a
vulnerability of relaying at the transport layer by a gateway. At some
point, checking and rewriting or dropping packets gets expensive enough that
you may as well have spent your time hardning the stack, especially when
the machine's remote services may need hardening anyway.
The fact remains that if you took FW1 on Solaris, and the FWTK on the same
platform, and were to allow NetBIOS in (not that it would be prudent in most
cases), under FW1 the "protected" clients would be vulnerable to OOB, under a
circuit level relay like plug-gw they wouldn't. Plug-gw isn't even an
application layer proxy, but illustrates the difference, and point quite
clearly. Just as relaying at the application layer opens you up to
application layer attacks with a proxy (and a packet filter, stateful or
not), relaying at the transport layer leaves you open to transport layer
attacks.
Nuff said,
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
|
|
