>>>>> "Mikael" == Mikael Olsson <[EMAIL PROTECTED]> writes:
Mikael> There is no way to stop all variants of the FTP ALG data channel
Mikael> exploits if you want active mode FTP to work from your protected
Mikael> clients.
Mikael> Period.
OK, so let's take this from the top. Your stated threat is bogus PORT
commands coming from internal clients.
Scenario 1: All inbound connections are denied
You're safe. Bogus or valid - "kill them all, God will know his own".
Scenario 2: Stateless packet filter, allowing PORT initiated back connections
You already allowed anyone in the universe to connect to the anonymous port
range on your boxen, so why are you worried about FTP client spoofing?
Scenario 3: Protocol inspection, via ALG or sufficiently advanced "Stateful
inspection" (hereafter referred to as a "proxy"), allowing PORT initiated
back connections
I am going to assert the following (which are _not_ true with many of the
current firewalls, as they were written by monkeys randomly typing code
until it compiled):
- The proxy validates client and server IP addresses
- The proxy validates client port to be a valid anonymous port
- The proxy actually follows the protocol, and doesn't just grep for strings
You're already better off than Scenario 2. You are still vulnerable to
someone somehow convincing your machine to make a valid FTP session and
issue a PORT command opening up a nasty port (say, 2049/NFS on a BSD-ish
machine whose anonymous port range is 1024-5200 or so). Yes, I can (and do)
exclude 2049 as a valid port, but there are other protocols that don't have
nice, fixed ports, so lets go with it.
So, you've somehow done this. Ummm... how? Ah! Java will happily do it, if
you have it enabled. So don't. If you must, then skip to Scenario 4. Ah-ha!
You say you can make Netscape do interesting things with bizarre FTP
URLs. Well, no, you can't, if the proxy is actually doing anything real. Of
course, Firewall-1 will happily wag it's tail, but then we knew it sucked
already (did the latest patch make it any less suckful?)
Any other candidates? I'd really like to know if there's anything else (that
isn't itself a trojan of some form). If so, I haven't heard of it.
Scenario 4: As in Scenario 3, but forbid client-initiated PORT
commands. Proxy translates PASV requests into PORT commands on behalf of the
client.
The best solution of all. It _does_ require PASV-aware clients, but those
are common enough these days. And it returns an error on PORT commands,
preventing annoying timeouts. It does require allowing inbound connections
to your proxy, but if that box isn't secure, you're in serious trouble. And
you can specify the port range required, to make it as small as you like,
and wherever you like. It also works with servers that have disabled PASV
(or are behind packet filters that throw away your connections).
I coded (and published) the basics of this as a patch to the FWTK many years
ago. Dunno' if it ever went anywhere - I haven't touched the toolkit in a
long time. It certainly wasn't rocket science.
Now, as long as I'm rambling on about FTP, I might as well cover the other
half of the problem - somebody else's client connecting to your server.
The threat: your server is convinced to emit a bogus 227 PASV response
bracketed by CRLFs. The only way I know to do this on a non-psychotic FTP
server is to have a local account on the FTP server, create a directory with
embedded CRLFs, and create a symlink to said directory. But, this could
still be an issue. To fix it:
Option 1: Have the server properly NULL escape CR (as explained in the
latest FTP i18n RFC). Have your proxy not fall for anything but a properly
CRLF delimited response to a valid command.
Option 2: Disable PASV on the server, and have your proxy do PASV to PORT
translation. See Scenario 4 in the client case, above. The proxy ignores (or
better yet, logs the hell out of) 227 PASV responses from the server.
Option 3: The server responds in standard fashion to some command that
returns a copy of a submitted argument. For example:
help kajshdfkjashdfkshfdsf
502 Unknown command KAJSHDFKJASHDFKSHFDSF.
Given this, one can implement a lockstep protocol around "dangerous"
commands, such as PASV and PORT. e.g.:
HELP <token1>
502 Unknown command <token1>.
PASV
227 Entering Passive Mode (I1,I2,I3,I4,P1,P2)
HELP <token2>
502 Unknown command <token2>.
One must, of course, ensure that <token1> and <token2> are unpredictable.
This ensures that no bogus CRLFs have been returned by the server, and that
the answer is authentic, within the bounds of an unauthenticated TCP session
(if your session is hijacked, all bets are off, but you already knew that).
--
Carson Gaspar -- [EMAIL PROTECTED]
Security Consultant at Large -- For Hire or Rent - E-mail to Enquire
Queen Trapped in a Butch Body
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
