Firewall Wizards mailing list archives
Re: VM system for firewall use (fwd)
From: "Paul D. Robertson" <paul () compuwar net>
Date: Tue, 12 Oct 2004 11:06:31 -0400 (EDT)
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
Current thread:
- Re: VM system for firewall use (fwd) Paul D. Robertson (Oct 12)