Security Basics 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. To simplify: 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 VMotion VM Migration 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 http://taviso.decsystem.org/virtsec.pdf 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 Regards, Craig Wright GSE etc Craig Wright 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 http://www.bdo.com.au/ 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. -----Original Message----- 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 <snip>
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.
</snip> 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 article, "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 software." 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 virtualisation: Single box Vm1 - Mail Vm2 - Name Vm3 - Web 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 vm)) 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 ? Cheers, Al PS Agreed: internal systems *should* mirror production - it's quite possible these days that production systems *will* be virtual :D aced on th??st??
Current thread:
- Re: Deny access to copy files, (continued)
- Message not available
- Re: Deny access to copy files Shreyas Zare (Jun 23)
- Message not available
- Re: Deny access to copy files Shreyas Zare (Jun 23)
- Message not available
- Re: Deny access to copy files Shreyas Zare (Jun 24)
- Re: Deny access to copy files Ansgar -59cobalt- Wiechers (Jun 24)
- Message not available
- Message not available
- Message not available
- Re: Deny access to copy files Shreyas Zare (Jun 24)
- Re: Deny access to copy files Jeremy Winder (Jun 24)
- Re: Re: Deny access to copy files Breno BF (Jun 03)
- Re: Deny access to copy files Al MailingList (Jun 11)
- RE: Deny access to copy files Craig Wright (Jun 12)