> -----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.]
