RE: Deny access to copy files

[Craig Wright <Craig.Wright () bdo com au>]

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??