Absolutely correct, one had to install CyberPatrol separately..
At 09:12 AM 9/1/00 +0930, Ben Nagy wrote:
> > -----Original Message-----
> > From: Mikael Olsson [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, 1 September 2000 5:47 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: An eye opener for firewall lovers
> >
> >
> >
> > [EMAIL PROTECTED] wrote:
> > >
> > > Actually, it was not really a remot compromise but an
> > oversight in QA,
> > > where such that when the pieces were integrated, the
> > Gauntlet firewall was
> > > then vulnerable.
> >
> > Blah. It was delivered r00table out-of-the-box. This makes
> > the finished
> > product vulnerable. Period. Now, if this had been end users installing
> > stuff on the firewall, it had been another matter, but it wasn't.
>
>Are you sure about that, Mike? Wasn't the problem with CyberPatrol? In all
>the NT Gauntlet installs I've done Cyberpatrol is not installed by default.
>I remember looking at it and thinking "Hmm. Eval software produced by the
>makers of Barbie and Ken. Should I load this up? Hmm..."
>
> >
> > To me, this just proves again that you shouldn't load one single
> > machine up with a bazillion of services. Separate machines is
> > the way to go.
>
>Yeah yeah. You're preaching to the converted. ;)
>
> >
> >
> > To steer this in another direction and reconnect to my "Basic firewall
> > design concepts" post from two weeks ago (Hi, Jefferey! :)), I'd like
> > to talk a bit about sidewinder again. Well, actually, more about the
> > concept of "trusted OSes" than sidewinder, but since that firewall is
> > a representative of said category, here goes...
> >
> > Now, the tOS idea is to compartmentalize the operating environment so
> > that a compromised FTP proxy process won't gain control over the
> > firewall kernel or other processes. Fine. Assume that this works.
> > Being a C and assembler coder, I don't believe it really does, but
> > that's another story. Let's just for the sake of argument assume
> > that it actually works.
>
>I don't know quite enough OS theory to offer any cogent argument here, but
>I'm assured that it actually does work. From what I've read, the problem is
>that the system process in "normal" OSes has access to _all_ the good stuff.
>If you're using a capability based system then you can assign only the bits
>of the "good stuff" you need to a thread - this means that you don't need to
>give any thread full system privileges for any period of time - and that's
>where most of the problems occur in our normal OSes.
>
> >
> > Now, assume that said FTP proxy process is compromised and completely
> > under the control of an external user. What, pray tell, keeps this
> > FTP proxy from connecting to pretty much any port on any host
> > behind the firewall?
>
>You're assuming that you can effectively replace the proxy thread with
>arbitrary code, which is deeply non-trivial. Most remote 'sploits involve
>overwriting small, selected pieces of memory which then affect other
>threads. I'm far from convinced that this is possible, but it's certainly an
>interesting idea. Any trusted OS designers out there?
>
> > Regards,
> > Mikael Olsson
>
>Cheers,
>
>--
>Ben Nagy
>Network Consultant, Volante Solutions
>PGP Key ID: 0x1A86E304 Mobile: +61 414 411 520
>-
>[To unsubscribe, send mail to [EMAIL PROTECTED] with
>"unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
