mailing list archives
RE: Deny access to copy files
From: Craig Wright <Craig.Wright () bdo com au>
Date: Thu, 12 Jun 2008 09:24:04 +1000
If we make the assumption that all configurations, applications and hosts are locked down the same way. From a security
and risk perspective.
3 hosts with individual CHMOD gaols
Is better than
3 hosts each with a single app Is comparable to 3 VMs each with a single app in a chmod gaol
Is better than
3 VMs each with a single app
Is better than
1 host with 3 Chmod gaols
Is better than
I host with 3 apps all running together
As for cost, I can get 3 hosts for less than $1500. For a small firm where the issue is not space cooling etc, the cost
argument is flawed.
" quite possible these days that production systems *will* be virtual"
That is fine as long as the risk is quantified correctly and the appropriate controls are in place. If all systems are
on the same zone then this is a lessor risk than when people share zones (ie DMZ and production on the same hypervisor
- and I have seen Gartner present this as well as a host outside the firewall etc).
As the network on a VM is a hub based environment, the issue with separate zones is that information can leak. That is
internal and external segments can see each other. There are mitigating controls, but these are controls that are not
necessary on physical servers and also ones that are commonly neglected.
Also remember that the networks with VMs are not switched. This is they are in effect hubs. It is simple to sniff all
traffic from host to host. Adding separate cards can help, but increases cost.
Have a look at:
Xensploit - http://www.eecs.umich.edu/techreports/cse/2007/CSE-TR-539-07.pdf
A quote from the recent Blackhat:
"One of the underlying themes of my presentation is that we've been continually breaking down isolations barriers that
provide security in exchange for new functionality," Oberheide.
Oberheide noted that systems have moved from physical machines where state is protected by hardware mechanisms such as
the MMU. Virtual machines protect the machine state in the isolation boundaries of a software layer such as the
VMM/Hypervisor, ".which, as we've seen, often fails in its isolation," to VM migration where the machine state is
exposed to the local network. So there are controls that can be added to reduce the risk, but these are additional
controls not needed on real systems.
Also have a read of:
" An Empirical Study into the Security Exposure to Hosts of Hostile Virtualized Environments" Tavis Ormandy
Some further reading:
T. Shelton, "VMware natd heap overflow", http://lists.grok.org.uk/pipermail/full-disclosure/2005-December/040442.html
G. Delalleau, "Large Memory Management Vulnerabilities", http://cansecwest.com/core05/memory_vulns_delalleau.pdf
Popek, G. J. and Goldberg, R. P. 1974. Formal requirements for virtualizable
third generation architectures. Commun. ACM 17, 7 (Jul. 1974), 412-421
K. Kato, "VMware Backdoor", http://chitchat.at.infoseek.co.jp/vmware/backdoor.html
Craig Wright GSE etc
Manager, Risk Advisory Services
Direct : +61 2 9286 5497
Craig.Wright () bdo com au
+61 417 683 914
BDO Kendalls (NSW-VIC) Pty. Ltd.
Level 19, 2 Market Street Sydney NSW 2000
GPO BOX 2551 Sydney NSW 2001
Fax +61 2 9993 9497
The information in this email and any attachments is confidential. If you are not the named addressee you must not
read, print, copy, distribute, or use in any way this transmission or any information it contains. If you have received
this message in error, please notify the sender by return email, destroy all copies and delete it from your system.
Any views expressed in this message are those of the individual sender and not necessarily endorsed by BDO Kendalls.
You may not rely on this message as advice unless subsequently confirmed by fax or letter signed by a Partner or
Director of BDO Kendalls. It is your responsibility to scan this communication and any files attached for computer
viruses and other defects. BDO Kendalls does not accept liability for any loss or damage however caused which may
result from this communication or any files attached. A full version of the BDO Kendalls disclaimer, and our Privacy
statement, can be found on the BDO Kendalls website at http://www.bdo.com.au/ or by emailing mailto:administrator ()
bdo com au
BDO Kendalls is a national association of separate partnerships and entities. Liability limited by a scheme approved
under Professional Standards Legislation.
From: Al MailingList [mailto:alpal.mailinglist () gmail com]
Sent: Thursday, 12 June 2008 12:56 AM
To: Craig Wright
Cc: security-basics () securityfocus com
Subject: Re: Deny access to copy files
But to prove the negative (and to paraphrase a little from the Burton group).
3. Separation reduces risk. Running several systems on the same hypervisor makes them more (not less vulnerable). All
of the systems are just as vulnerable as a locked down host on a system with the added benefit of also having the
risk from the hypervisor abstracted onto them.
Ignoring the discussion about development boxes for a moment... I'm a
bit confused at what you're getting at here - I thought in law 3 the
article was alluding to the fact that using VMs as separation *was* a
good idea to offset increased risk from the hypervisor? Quoting the
"One of the ways to benefit from virtualization is to separate various
functions into their own isolated operating environments. An even
better way is to separate data as well. Either type of separation
provides an opportunity to reduce the risk added by the virtualization
As Greg pointed out, non VMware solution in the case a client only
wants to buy a single physical box:
- Mail Server
- Name Server
- Web Server
obviously a large attack surface, and in the event a single service is
compromised, there go the other two services and associated data.
Obviously (I think? :) ) chroot and priv separation is a good idea
here. A different way of implementing separation is of course
As you point out, the attack surface is now slightly bigger per
service (if you +hypervisor), but in general two compromises are now
required to compromise all three services (exploit against one of the
services and then compromise of priv separation mechanism (chroot or
Have I missed something? Are you also suggesting chrooting services is
bad idea? I agree with your statement about cost reduction - if cost
doesn't factor into the equation, then by far the best choice is a
physically separate box per service. But can you not also then argue
that with certain constraints placed on the scenario (i.e. I can
afford one physical box), separation does reduce resultant risk (by
reducing severity of a compromise)?
Just a final note out of curiosity, you state:
"Risk = hypervisor_risk + Host_risk"
(which I understand...), but I was wondering, do you have an example
of a vulnerability that would affect virtual machine for an internet
based service? I mean I know vulnerabilities like CVE-2008-1340 are
serious, but obviously they don't increase the initial risk of, say,
an email server being compromised. Examples being a powerful thing, I
was curious in the scenario I presented above (3 vms... 1 runs mail, 1
runs name server, and one runs web) if you could point me at a CVE
that would demonstrate the +hypervisor_risk ?
PS Agreed: internal systems *should* mirror production - it's quite
possible these days that production systems *will* be virtual :D
aced on th??st??
Re: Re: Deny access to copy files cgmicro (Jun 02)
Deny access to copy files Craig Wright (Jun 03)
RE: Deny access to copy files Craig Wright (Jun 04)
Re: Deny access to copy files glunadelaguila (Jun 19)