Re: Checkpoint FireWall-1 sanity check

[gaulse () ttown apci com (that kid in research...)]

Pardon me if this is a duplicate...I didn't get my first post back.

Hmmm, I have a few questions/comments about all of this... 

> No one has actually discussed the implications of the GUI running on the
> firewall and what dangers it may represent, if any?

Exactly, I'd like to hear/read anyone's comments on this.

> Have all the listening ports been plugged?
  ^^^^ ^^^ ^^^ ^^^^^^^^^ ^^^^^ ^^^^ ^^^^^^^
  Can some who "own/drive/smoke's one" please answer this?

> Do they export the GUI front end to client machines?
  ^^ ^^^^ ^^^^^^ ^^^ ^^^ ^^^^^ ^^^ ^^ ^^^^^^ ^^^^^^^^
  Again, can some who "own/drive/smoke's one" please answer this one too?
 
> I won't pretend to be an experienced cracker, but I have heard 
> that X has many security implications to consider - can anyone
> expand on this?

I won't pretend either but having "played around"...
X11R5 defines, and the way I see the MIT releases implemented, are two
mechanisms that can be used for secure access control. XDM-AUTHORIZATION-1,
which is similiar to the MAGIC-COOKIE stuff, but uses DES encryption to 
encrypt the authorization data that is passed between client and server. 
Now, to compile that scheme you need an implementation of DES in the file:

        /mit/Xdmcp/Wraphelp.c

Due to U.S. export regulations, I certainly hope this wasn't in the SunOS
distribution to Israel. If this was developed in Israel, please explain how
FireWall-1 dealt with this?

I can only assume they used SUN-DES-1, and this is based on the public key 
Sun Secure RPC system included with the SunOS releases.

Most servers also use a host access list file (/etc/X.hosts or equivalent if
it is a UNIX based box) to determine whether to grant access. If the client
is running on a host that is on the server's host access list, the connection
is granted (even if the authorization data is wrong!). The host access list 
will be empty if an authorization mechanism is in use.

Now, as far as I am aware "X" DOES NOT provide any protection from unauthorized
access to individual windows, pixmaps, or other obsenities, once a connection
has been made. Let me demonstrate...
If I'm a cracker and I write a program that gets or even guesses a windows
ID that my program didn't create, using a querytree request you can manipulate
or destroy the window. One of the oldest tricks is... 
   cat /dev/fb > [filename]; xloadimage -onroot FULL [filename]
here, you would have succesfully grabbed whatever was on the screen of that
Sun classic and wrote it to a file that you could redisplay for yourself.
Of course, this assumes that the SysAdmin didn't change the fb privleges,
if so, well I guess the cracker would have to obtain root permission first.

> Interesting.  If Firewall-1 gets a patent, I may be able to
> show prior art.

Can Firewall-1 get a patent in the U.S.A. w/o breaching anyone else's work?

> Again, we are talking about this RUNNING on the firewall.  Looking at
> it from the cracker perspective, what would be a weakness to exploit if
> a firewall was known to be running X?  Perhaps forge X packets and run
> a "lookalike" of the GUI for the unsuspecting admin to type away at?

Well, I hope what I tried to depict above serves as a weakness that one may
try to exploit.

At any rate, enough of this...can anyone help me out with the prior questions?
Thanx,

          I'm also lost, can you direct me to the information superhighway?
        ______________________________________________________________________
       ///                                                                   /
      ///            Stephen E. Gaul, Jr.                                   /
     ///  /\         Air Products and Chemicals, Inc.                      /
  __///  /__\        Lehigh Valley, PA 18001                              /
 ///_   ______   __  INET: gaulse () ttown apci com || gaulS () moravian edu   /
/////  /______\  \/  VOICE: (215) 481-7054                              /
 ///______________   FAX:   (215) 481-3988                             / 
//////////////////____________________________________________________/

  NOTE: These statements and opinions are mine, not those of APCI...