Re: VM system for firewall use (fwd)

["Paul D. Robertson" <paul () compuwar net>]

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