COMMAND
FireWall-1
SYSTEMS AFFECTED
FireWall-1
PROBLEM
Hugo Van Der Kooij found following. If one takes CheckPoint
FireWall-1 v4.0 SP4 (latest version) and build the following rule:
Source: Destination: Protocol: Action:
Any citrix-server winframe accept
Where citrix-server is a simple network object and winframe the
definition as created by CheckPoint. This rules allows winframe
sessions to pass but should stop other traffic as it does some
more packet analyses.
One customer tried to run FTP through it and saw an accept in the
log. But due to the lack of a server on the other side could not
establish wether or not there was a leak. Recreating this in the
lab with telnet showed the same. However putting a working
telnetd on port 1494 at the specific server did still not allow
anyone to enter the system. After initial TCP connection setup it
seems the firewall drops connections. But this will lead to two
weaknesses:
1. Any server defended by FireWall-1 could be subject to a DoS
attack if the server should accept TCP sessions at port
1494. The server allows the initial setup and then stops
forwarding.
(That's two dependencies but we are the people that allways
assume the worst as we are the ones that try to do the
worst in such case)
2. The log only shows a succesfull start of the session but
down not indicate any filtering. This leaves the operator
of the firewall in the dark wether or not a session was cut
off due to the missing winframe signature. So there is no
indication off foul play and everyone will be assuming
things are just fine.
(We all know that if a firewall is supposed to show dropped
packets that plenty of people will never look for trouble
in the sessions that are allowed.)
SOLUTION
At present CheckPoint has not seen any reason to see the above
issue as a weakness in their product. It's a weakness in the
winframe server, better yet in the TCP architecture itself.
Winframe is just as vulernable through a firewall as an SMTP or
FTP server, they all allow arbitrary connections.
However, the term weakness here refers to the fact that a dropped
session is not reported. It does not refer to a leak in the
defenses. The issue here is that in the log there is a report of
a successfull connection reported. The session never got beyond
the first 3 packets so the defense mechanisme is correct. But
there is nothing in the log that will give you a clue that the
firewall dropped a session. So, nothing yet.