[prev in list] [next in list] [prev in thread] [next in thread] 

List:       firewall-wizards
Subject:    Re: [fw-wiz] VM system for firewall use (fwd)
From:       "Paul D. Robertson" <paul () compuwar ! net>
Date:       2004-10-12 15:06:31
Message-ID: Pine.LNX.4.58.0410121105450.11205 () bat ! clueby4 ! org
[Download RAW message or body]

Forwarded by request

-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
paul@compuwar.net       which may have no basis whatsoever in fact."
probertson@trusecure.com Director of Risk Assessment TruSecure Corporation

---------- Forwarded message ----------
Date: Tue, 12 Oct 2004 11:05:18 -0400 (EDT)
From: Paul D. Robertson <paul@compuwar.net>
To: ArkanoiD <ark@eltex.net>
Subject: Re: [fw-wiz] VM system for firewall use

On Tue, 12 Oct 2004, ArkanoiD wrote:

> > > Why? If the code compromised is, say, content filter that has no access to
> > > real hardware, just runs on virtual disk drive and talks to a kind of looback
> > > interface to other components, the impact is just malicious user may
> > > bypass this particular filter, and nothing more (there are more dangers
> > > in real world since if it was taken over there are more attacks to other
> > > components accessible from this point, but that risk can be minimized as well)
> >
> > The problem is that you get into a position where the interface in and out
> > of the virtualization has to be hardened to provide assurance, and since
> > you're doing a one-off model, it's really difficult to provide that
> > assurance.  If I can get data in to compromise it, then I can likely get
> > data back out, and from there, it's an exercise in inching forward for
> > an attacker.  Granted, you're out of script kiddie land, but jails pretty
> > much give you that- so I'm not convinced that the overhead is worth-while
> > for sets of things that have to intercommunicate a lot (like your
> > examples.)
>
> Say, i have a proxy that forwards data from one network interface to another.
> It does some simple structure parsing and then passes content via a kind
> of "controlled loopback" to an inspection service, that runs in virtual
> environment where no network interfaces except "controlled loopback"
> exist, no disk drives except virtual drive it runs on, and no other hardware
> except CPU and private address space. So if the filter is compromised,
> an attacker may use it to try to compromise the proxy it talks to or to
> compromise the virtual machine itself - there is just nothing more it can
> see and touch.

The issues here are:

1.  The filter gets all data anyway, so all data going through the proxy
is immediately subject to compromise (i.e. the filter can pass back
*anything* to compromise an internal machine (say send the next IE browser
a GDI exploit?) and the internal systems talk to the proxy.  You can
start to minimize this with a proxy for each direction, but likely any
error will be common to both pieces of code- it just means the attack has
to attack the "talks to the world" one first, then get the answer to go to
a vulnerable machine inside to compromise that direction.

2.  The virtualization must be complete and not contain errors.  Kernel
bugs *may* allow access to enough of the virtual machine's support
environment to compromise it unless it's well-written.  This includes the
address space the virtualization environment shares with the real OS to
talk via the controlled loopback interface.

> > I much prefer a trusted computing base, because then the
> > intercommunication is labeled and the system takes care of who can see what
> > and what they can do after they see it.  It also scales much more robustly
> > than trying to cram multiple VMs into a single RM.  I could be wrong- and
> > there's something to be said for putting in as much protection as possible
> > anyway- I'm just not sure the trade-offs will be all that good.
>
> Maybe it does worth trying to combine that methods.. Will have to figure
> out how ;-)

I'm just happy to see how far along TrustedBSD is- I hadn't looked in a
while, and there's more than enough there to spend a *lot* of time on!

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
paul@compuwar.net       which may have no basis whatsoever in fact."
probertson@trusecure.com Director of Risk Assessment TruSecure Corporation
_______________________________________________
firewall-wizards mailing list
firewall-wizards@honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
[prev in list] [next in list] [prev in thread] [next in thread]