If I may interject in this conversation for a moment...
Firewall-1 (and, understand I'm used to FW1 on solaris)
gets first crack at the packets, decides if they meet whatever
criteria, and then passes them on to the IP stack that comes
with the OS. It doesn't replace the stack per se, it still relies on
the native OS IP driver to route packets and such, but hooks the OS
such that the FW1 kernel gets to look at the packet first.
On my firewall-1 machine, I've got the rules set so that no one
is allowed to connect to the firewall machine, i.e. drop all packets
with a destination address of the firewall itself.
Now, it looks like the NT box in question did not have such a rule,
so port 139 was "exposed." There may have been a reason for
this, or it may have been oversight, or it may be a limitation of the FW1
implementation on NT, I don't know.
I do, however, think it's an extraordinarily bad idea.
Ryan
---------- Previous Message ----------
To: jk, bdboyle
cc: firewalls
From: minorc @ reston.ans.net ("Conrad Minor") @ smtp
Date: 06/05/97 01:39:32 PM
Subject: Re: [FW1] Out of Band Data Attack against NT-Hosts
All,
This of course doesn't address the problem with the FW1. It is just to
refute the notion that NT is a completely closed OS.
Any firewall worth it's salt won't be running the native NT stack
unmodified. How for example would you plumb something like stateful
inspection onto an NT box without kernel changes? There are several methods
of modifying the stack to harden it against attack or change the way it
operates. The first would be to shim the stack ie putting a driver between
the Ethernet card drivers and the stack itself. NT has built in support for
this. Just read the DDK documentation. NT 4.0 has even better support then
3.51 since Msoft has added calls that let you dynamically hook into the
NDIS stuff. This is in fact that's how RAS is implemented (NDISWAN).
Another option of course is to replace the TCP stack all together. Centri
from Global Internet does that. Check out their web page. They completely
bypass the microsoft stack by building their own proprietory stack which
intercepts all packets coming to the firewall. They optionally will pass
packets to the Msoft stack depending on how your rules are configured.
Packet filter firewalls don't even need a TCP stack. Just hooks into the
NDIS routines that handle the reception and distribution of packets.
Probably could do this with another SHIM.
All of this is documented by Microsoft, The source code for sample drivers
are available as part of the DDK. While there are no sample SHIM drivers, a
buddy and I created one for NT3.51 in about a month. It was really a matter
of combining an existing ethernet driver with an existing protocol driver
and making them talk to each other.
NT even has source level debugging at the kernel layer. Name some UNIX
boxes that support that (not to suggest that one is better then the other,
just that NT kernel work is easier. Streams are pretty damn elegant).
Conrad
----------
> From: Bryan D. Boyle <bdboyle @
att .
com>
> To: Jyri Kaljundi <jk @
stallion .
ee>
> Cc: firewalls @
greatcircle .
com
> Subject: RE: [FW1] Out of Band Data Attack against NT-Hosts
> Date: Thursday, June 05, 1997 9:46 AM
>
> At 03:08 PM 6/5/97 +0300, you wrote:
>
> >You mean you can crash and NT FW-1 by sending OOB data to it?!
> >That's scary if it is true and should be addressed by Check Point ASAP!
> >
>
> It is a bogosity with NT and not with FW1. Can't be addressed by
Checkpoint,
> since the OS is not in their control. They can only operate (or be as
> secure as) at the least common denominator level of the underlying OS.
>
> >What I have always thought of FW-1 is that it operates at quite low
level
> >inside the OS kernel, that as long as you filter everything the network
> >bugs in the OS don't really matter, as the packets never reach FW-1.
>
> Nothing except MS code operates in the NT kernel. This problem is with
> what happens when you send oob data to a stack (MS) that is tightly
integrated
> with the OS (FW1 runs on top of this stuff, not in it...) and the
stack/OS
> interface and control mechanism itself is crap.
>
> Of course, on UN*X systems, this is not the case. This is a signal
example
> of the difference between designing for peer review of your security
model
> and designing for what gets good trade publication reviews.
>
> >
> >If sending some bytes of data to FW1 crashes it and the OS, this
> >combination (FW1+NT) should not be used as a firewall solution at all.
May
> >be someone from CP could explain, how much do the bugs in the OS matter
> >once FW1 is installed.
>
> If there is an overall architectural problem with NT as it is, then the
OS
> bugs matter A LOT. But, of course, those that say you can trust a black
box
> solution since the vendors are trustworthy are quite quiet on this
regard...
>
> I would agree that you should ignore NT as an OS platform in a
> security solution right now. Just my opinion, $.02 US, etc.
>
> Flames to /dev/null.
> --
> Bryan D. Boyle | LOGICAL: bdboyle @
att .
com 201-386-8584
> #include <disclaimer> | VIRTUAL: http://www.access.digex.net/~bdboyle
> AT&T Laboratories, Inc. | PHYSICAL: Whippany, NJ
> | HISTORICAL: HQ, 6th Battalion, Army of No. VA.
> "What country can preserve its liberties, if its rulers are not warned
> from time to time, that its people preserve the spirit of resistance?"
> -Thomas Jefferson, 1787
Follow-Ups:
|
|
