Bugtraq mailing list archives
firewall-1: old broadcast address hole?
From: tom () NETVISION BE (Tom Vandepoel)
Date: Thu, 24 Apr 1997 14:05:27 +0200
Hello, This mail is about something checkpoint has overlooked in it's firewall-1 v2.1. I believe it to be a flaw in lots of ruleset implementations anywhere. Say I build a ruleset around the following assumptions: First of all, I want to allow administrators access to the firewall. Second, I want to block all other access to the firewall itself. Third, I want to allow some services from the inside nets to the outside. To implemement this, one would have the following ruleset structure: 1) Allow access to firewall for adminstrator access 2) Block all other access to the firewall object 3) Allow traffic from inside net to any for certain services Now, this will correctly block all access to the firewall's interface addresses for non admin access. However, if you use the network address of, say, the external interface of the firewall, as your destination address. The ruleset will not block this in the second rule, and it will match on the third. In some cases (in my case on Solaris 2.5 sparc) this can actually be used to connect to services on the firewall. I'm not sure if this works with all tcp implementations, but I think this has something to do with the deprecated use of the subnet address as the all-subnets directed broadcast address. Also, I've seen this only in a situation where the network was subnetted. I will try to reproduce this for non-subnet situations as soon as I can find some time. This particular problem situation is not as much a threat, as it will only allow access to firewall services from the internal network. However, if liberal access is allowed from outside too, this may be exploitable from outside as well. All it takes is a rule allowing a service to anywhere, or a network including the firewall. This will be enough to match the network address... A fix would be to define *host* objects for each of these network addresses and deny access to them too in the second rule... I sent this to bugtraq too to give checkpoint a little motivation to look into this problem... Tom. -- | Tom Vandepoel | Sr.Network Engineer | NetVision nv tom () netvision be http://www.netvision.be | | T. 32-16-31.00.15 | F. 32-16-31.00.29 For geekcode and other info, check http://www.netvision.be/tom/gc.html
Current thread:
- SNI-12: BIND Vulnerabilities and Solutions Oliver Friedrichs (Apr 22)
- Re: SNI-12: BIND Vulnerabilities and Solutions Peter Koch (Apr 23)
- Re: SNI-12: BIND Vulnerabilities and Solutions Paul A Vixie (Apr 23)
- Re: SNI-12: BIND Vulnerabilities and Solutions (+ more problems) Johannes Erdfelt (Apr 23)
- Re: SNI-12: BIND Vulnerabilities and Solutions (+ more problems) Gene Spafford (Apr 23)
- Re: SNI-12: BIND Vulnerabilities and Solutions (+ more problems) Michael K. Sanders (Apr 23)
- Re: SNI-12: BIND Vulnerabilities and Solutions (+ more problems) Johannes Erdfelt (Apr 23)
- Re: SNI-12: BIND Vulnerabilities and Solutions (+ more problems) Yiorgos Adamopoulos (Apr 24)
- firewall-1: old broadcast address hole? Tom Vandepoel (Apr 24)
- CERT Advisory CA-97.10 - Vulnerability in Natural Language Service Aleph One (Apr 24)
- CERT Vendor-Initiated Bulletin VB-97.02 - Guestbook Script Vul Aleph One (Apr 24)
- [linux-security] Linux squake security hole (provides root if Aleph One (Apr 24)
- Re: SNI-12: BIND Vulnerabilities and Solutions Peter Koch (Apr 23)
- <Possible follow-ups>
- Re: SNI-12: BIND Vulnerabilities and Solutions David Wagner (Apr 22)
- Re: SNI-12: BIND Vulnerabilities and Solutions Theo de Raadt (Apr 22)
- ANUNCIO: Nueva lista sobre seguridad, en espanol Ivan Arce,CORE (Apr 22)
- Re: ANUNCIO: Nueva lista sobre seguridad, en espanol The CyberFish (Apr 23)
- Re: SNI-12: BIND Vulnerabilities and Solutions David Wagner (Apr 23)
- Re: SNI-12: BIND Vulnerabilities and Solutions David Wagner (Apr 23)