Re: Phrack #60: "Java tears down the Firewall"

[Mikael Olsson <mikael.olsson () clavister com>]

"Magosányi Árpád" wrote:
> [SPFs can't enforce single-direction data channels?]
>
> SPFs just _try_ to do exactly that. As I have mentioned it is not
> just extremely complicated to do with a packet filter, but also impossible.
> (Because recognition of a known pattern in a tcp traffic with packet filters is
> theoretically impossible. See http://www.insecure.org/stf/secnet_ids/ for more details.)

I've come up with not one but three separate ways of using FTP to fool 
SPFs that grep for strings in raw TCP segments.  Believe me, I know about 
these problems :)  
(Note that not all of the "IDS evasion" points apply here. The FW always
 sees all traffic. The same can't always be said for IDSes.)

My point is: even though one can't reliably make sure that the client
said "RETR" or "STOR" to determine the data channel direction, one can
most certainly make sure that the data channel only passes data in
one direction.  The existence or absence of data in a direction is
more a layer 4 issue than it is a layer 7 issue, and SPFs arguably
have more control over layer 4 than proxies do (not that it matters here).

And: the attacker really doesn't need to "fool" the firewall into thinking
that it said "RETR" when in fact it said "STOR".  It can just say what it
wanted to in the first place; "fooling" the fw doesn't buy you anything
in this scenario.

Why am I making this distinction?  Well, I'm a nit-picker, for one, but
also because I believe that a box that goes full ALG on the FTP control
channel and then SPF on data channels can safely do so; evading the 
single-direction protection is, IMHO, not possible even in this scenario.
I'll gladly listen if you can prove me wrong, but I don't think you can.
(No, don't bring data channel content inspection into the debate. 
 That's a different argument.)


But, yeah, I firmly believe that you shouldn't attempt to analyze the
FTP control channel without going fully ALG on it, so if _that's_ what
you've been saying, no need to argue: I agree fully.


> [difficult to implement attacks over unidirectional channels, or not?]
>
> I was imlpying those attacks where you should do some communication
> back and forth until you reach the state where the vulnerability lies.
> (Yes, you can predict the answers, but with what probability?)

For _some_ protocols, this is indeed exceedingly difficult.
For some, it isn't, even if they vulnerability lies deep in the protocol.

Example of non-deep exploitable situations / protocols:

- HTTP (and as I said, especially HTTP-using systems management agents, 
  which tend to live on high ports and be rife with buffer overruns)
- MS-SQL (There was a buffer overrun in the very first 
          packet not long ago?)
- Any service that does a reverse DNS lookup of the remote and
  lives on a *nix box with an unpatched resolver library. >:]

Examples of (theoretically) exploitable "deep" protocols:

- FTP commands that can only be executed after authentication
  (assuming you can authenticate, or the server allows anon).
  Just stack the commands in one segment, like
  "USER anonymous\nPASS asdf () asdf com\nSITE EXEC ....\n"

- SMTP "data" buffer overrun (hey! it's just an example!):
  "HELO asdf.com\nMAIL FROM ...\nRCPT TO ...\nDATA <overrun?>\n"


Now, if you've got a protocol that hands off truly random challenges
or something else very-hard-to-predict that the client needs to 
reproduce, the attack is indeed exceedingly difficult. 

My point, however, is: I think that there's plenty of easily-exploited 
protocols to choose from even if unidirectional data channels are 
enforced.  Especially since a java application like this can keep 
running for quite some time (in a pop-under?) and sequentially poke 
holes for all ports 1024-65535 or do even more evil things (no, I
don't particularily want to give the kiddies "good" ideas :))


> [and now for something completely different :)]
>
> I think that the main point of the firewall is being a security device, enforcing
> a policy. I expect a security device to defend against attacks it is supposed to
> withstand. A firewall is in an ideal case is supposed to defend against all attacks.
> In the real word it should defend against all handleable (think of DoS) classes
> of attacks I can think of. Packet filtering routers are not in this
> category. Most of the firewall are also not in this category, but firewalls
> in theory could be, while packet filters couldn't.
>
> (The last part is the old proxy/packet filter flamewar. Sorry about that.)

Ah, here's where we differ in opinion.  To me, a firewall is just 
something that implements my security policy.  Now, if my security
policy is "I want a red rotating light and a klaxon to go off whenever
there's inbound traffic", this light and klaxon (and sensor) would be
my firewall.  (And I _still_ want to try and get that device certified 
according to EAL7 darnit! Anyone here want to front me $50K? :))

Seriously though, the "collection of systems" thinking goes deep with me.
My favourite design is centered around a small enough to be trusted SPF 
and has "helper" proxies around it (NOT! on the same box!).  For high-
security scenarios, I wouldn't let much (any?) traffic between trusted
and untrusted networks pass only through the SPF - it'd have to pass 
through one or more of the helper proxies.

Sound reasonable? :) 

(If you want to keep talking about this, I'm all for it. Just please
 cut this bit out of this mail and move it to a new thread.
 I suggest a subject of "Proxy vs SPF" so others know to ignore us :))

-- 
Mikael Olsson, Clavister AB
Storgatan 12, Box 393, SE-891 28 ÖRNSKÖLDSVIK, Sweden
Phone: +46 (0)660 29 92 00   Mobile: +46 (0)70 26 222 05
Fax: +46 (0)660 122 50       WWW: http://www.clavister.com
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards