Jochen,
I think this depends on which version of FW-1 you are running.
V4.1 behaves as you've described below, but for V4.0, no matter what implied
rules you have switched on in your policy, you have:
grep "^#include" wo_control.pf
#include "fwui_head.def"
#include "user.def"
#include "init.def"
#include "code.def"
#include "fwui_trail.def"
Then in the code.def, you have
/*
* Intercept decryption requests. This rule intercept the first packet in
* the session. The first packet needs special treatment by the
encrypt_intrcpt
* trap because this GW is not the IP-destination of the packet.
*
* For SecuRemote, we check whether <srrdpcon> is in the rdp table.
*
* The packet is held. If the daemon decides to take care of the request,
the
* packet is dropped. Otherwise, it releases the packet.
*/
#ifndef NO_ENCRYPTION_FEATURES
/* Non-encryption versions of these follow... */
inbound all@all {
accept
RDPCRYPTF,
((<rdpconn> in rdp_table)
or
(<srrdpconn> in rdp_table)
or
(log packet<-1> new_encrypt_intrcpt, hold));
}
/*
* All other RDP packets of the decryption session will be targeted to a
* specifice host which could be this GW (on which the inspection is done)
* or other GWs along the way.
*/
eitherbound all@all {
accept
RDPCRYPT;
}
So it would appear that this is included no matter what your implied policy
rules are.
Laters,
Paul
-----Original Message-----
From: Jochen Bauer [mailto:jtb@inside-security.de]
Sent: Wednesday, July 11, 2001 7:45 PM
To: bugtraqat_private
Subject: Re: Check Point response to RDP Bypass
On Wed, Jul 11, 2001 at 11:41:23AM +0200, Johan Lindqvist wrote:
> The original advisory
> (http://www.inside-security.de/advisories/fw1_rdp.html) says that a
> workaround is to "Deactivate implied rules in the Check Point policy
editor
> (and build your own rules for management connections).". I've not been
able
> to find any changes in the INSPECT code generated to confirm that not
using
> the implied rules from "Policy/properties/Security policy/Implied
> rules/Accept VPN-1 & FireWall-1 Control Connection"
Hmm.. strange. I cannot reproduce this. Here's the test i carried out:
I set up a policy with all implied rules, the policy file w_control.W
is attached to this mail. From this policy the INSPECT file w_control.pf
was generated (also attached). The relevant part of this file is:
[...]
#define REVERSE_UDP 1
#include "code.def"
accept_fw1_connections; <-----
accept_proxied_conns;
enable_radius_queries;
enable_tacacs_queries;
[...]
accept_fw1_connections is defined in $FWDIR/lib/base.def:
#define accept_fw1_connections accept_fw1_connections1
accept_fw1_connections2
accept_fw1_connections3
and the macro "accept_fw1_connections3" includes "accept_fw1_rdp" which is
the flawed macro.
#define accept_fw1_connections3
[...]
accept_fw1_rdp;
So, the RDP vulnerability finally comes into the INSPECT
file "w_control.pf" with the macro "accept_fw1_connections".
However, if i go to the policy editor and uncheck policy->properties->
Security Policy->Implied Rules->VPN-1 & FireWall-1 Control Connections and
re-compile the policy (wo_control.W, see attachment), i get an INSPECT file
(wo_control.pf, see attachment) that does not make use of
"accept_fw1_connections" and does therefore not lead to this vulnerability.
I've also tested this with our proof of concept code. (BTW: I'm going to
post this code tomorrow on BUGRAQ)
Can you post the policy and INSPECT files you generated?
Jochen
--
Jochen Bauer | Tel: +49711 6868 7030
Inside Security IT Consulting GmbH | Fax: +49711 6868 7031
Nobelstr. 15 | email: jtb@inside-security.de
70569 Stuttgart, Germany | http://www.inside-security.de
This archive was generated by hypermail 2b30 : Sun Jul 15 2001 - 20:07:37 PDT