VMWare poor guest isolation design
This is a multipart message in MIME format.
------=_NextPart_000_007B_01C7E502.8FF4AA20
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
I have run across a design issue in VMware's scripting automation API that
diminishes VM guest/host isolation in such a manner to facilitate privilege
escalation, spreading of malware, and compromise of guest operating systems.
VMware's scripting API allows a malicious script on the host machine to
execute programs, open URLs, and perform other privileged operations on any
guest operating system open at the console, without requiring any
credentials on the guest operating system. Furthermore, the script can
execute programs even if you lock the desktop of the guest OS.
For example, if a non-admin user is logged in at the vm host, but logged in
to guest operating systems as an administrator, the script running as a
non-admin on the host can still execute admin-level scripts on the guests.
I obviously did not discover this issue--the API developers provided it as a
feature-I am simply pointing out the potential danger, that it was a poor
design decision, and that there is a need to establish best practices for
virtual machine guest and host isolation.
Background
Virtual machines have become a more integral part of the computing world and
are playing an increasing role in IT infrastructures. It is not uncommon to
use virtual machines for everything from testing to critical server roles.
One benefit of using virtual machines is that it allows you to work with
several operating systems on the same machine and provides effective
isolation between each operating system.
The VIX API provides an interface to manipulate virtual machines from the
host machine. This API is available on any machine with VMware Server or
Workstation installed. Certain commands-such as RunProgramInGuest -do
require authentication to run commands on a VMware guest OS, you can
instruct them to use the credentials of the user currently logged in at the
console. If no user is currently logged in, the command can wait until the
next user does log in.
The risk here is that although the guest OS is a separate operating system
environment, a script on the host machine can still execute programs in any
guest machine without knowing any actual login credentials. This would allow
malware to propagate to guest OS's without any additional credentials.
Scenario
Many IT professionals have begun to use virtual machines for critical
infrastructure systems. In my own environment I use specialized virtual
machines for development and administration. The snapshot features and easy
backup capabilities of virtual machines make them convenient for dedicated
administrative environments.
Since I-as well as many administrators-normally stay logged in to my desktop
as a non-admin user, it is convenient to have separate virtual machines for
performing administrative functions. I have also done this to gain further
isolation so that normal PC activities such as browsing the Internet and
reading e-mail do not compromise administrative access to my network.
The problem is that a malicious script running within the context of a
regular user on my desktop can run administrator-level scripts on any guest
I am currently logged in to. Using Ctrl+Alt+Del to lock the desktop of those
machines does not prevent VIX from executing commands on the guest. Even if
I log out of each guest machine the malware can just queue the command to
run the next time I log in at the console of the guest OS.
Remediation
I contacted VMWare about this issue several months ago and they responded
that his was "a very difficult design choice". Their response was that
anyone who is able to connect to a guest via the VIX api would also have the
capability of accessing the virtual disk files of the machine and compromise
the guest that way as well.
While that is true, it is also possible to use full disk encryption and
other countermeasures that prevent access to a host resulting in compromise
of the guests. Furthermore, being able to automate something is a big deal
when it comes to spreading malware. Give me access to any system on a
foreign network with user-level credentials and before too long I can
acquire full admin access, but for a worm to be able to automate that in
seconds is something completely different.
But rather than try to argue with VMWare about the severity of the issue, I
chose to simply make you all aware that the potential is there and you can
decide for yourselves.
Fortunately, there is an undocumented switch to turn this off. In the VMX
config file, you can add the following:
guest.commands.anonGuestCommandsRunAsConsoleUser=FALSE
You can also set this on the host-wide configuration file, so it will
override the config setting in every VM.
So with that, I would like to establish a best practice for virtual machine
guest/host isolation:
A virtual server host should never provide any mechanism that, by default,
allows guest-to-host or host-to-guest access without having to follow
standard authentication procedures and protocols for the target operating
system.
This original post can be found here:
http://xato.net/bl/2007/08/22/vmware-guest-isolation-vulnerability/
Mark Burnett
http://xato.net
------=_NextPart_000_007B_01C7E502.8FF4AA20
Content-Type: application/x-pkcs7-signature;
name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="smime.p7s"
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJFTCCAp0w
ggIGoAMCAQICEGPfoVbHsvJ96WW+eyrXmCYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUwOTE2MzcxMVoXDTA4MDUwODE2Mzcx
MVowPTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEaMBgGCSqGSIb3DQEJARYLbWJA
eGF0by5uZXQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKolIXs769PIPDAOlJt+EUM4yZL1
1F+ZxlNfufFstZzlt8j45BkyeMlmBbo9aFRWAzExoGhZOhzcnYpuanoM0ucVnH5cvMXNC3pafzlW
1prY5+onccbytJ3mvaFjcZObDd1PICFtgAwcRGhWDAPRZZ5P8k44oeWTI6GYyiB7Y0WVAgMBAAGj
eTB3MA4GA1UdDwEB/wQEAwIHgDARBglghkgBhvhCAQEEBAMCBaAwLAYFK2UBBAEEIzAhAgEAMBww
GgIBBAQVODN6d3ZHVHo2cDd3R2pDa3NUSlpBMBYGA1UdEQQPMA2BC21iQHhhdG8ubmV0MAwGA1Ud
EwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAMvqv9ySINTLIhcRINi/4wEAQQS18jKXmFSC+iFn9
ynWEvMLbxXkWk811NRTZDKksG8O5TVsHmtwS1y2S2ykRU7xsvgSeeg7hNjv0N9AQD1S3OZQS3ruh
AXR5AK+yvS9pfl8N7RynxS3tCVtZWlD3fKqMBp68FD38cwtomJtw23YwggMtMIIClqADAgECAgEA
MA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIw
EAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9D
ZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwg
RnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20w
HhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgT
DFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs
dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMb
VGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl
bWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRkW3HpR9gM
UbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP6E0PcR9A
OKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9edvlWsQc
uQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O+PWWpWdi
KqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyirNx54+du
AEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1RhGvk+NHO
d6KBMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNV
BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29u
c3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE
AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1m
cmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkG
A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcC
Y1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XR
xSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYD
VR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h
aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi
ZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4
Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vf
ldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAaIwggGeAgEBMHYwYjEL
MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV
BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBj36FWx7Lyfellvnsq15gm
MAkGBSsOAwIaBQCggYMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN
MDcwODIzMDMyMjM3WjAjBgkqhkiG9w0BCQQxFgQUEOD9+0fN5UisOJ6c9Rpoi5CCQOIwJAYJKoZI
hvcNAQkPMRcwFTAHBgUrDgMCGjAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASBgAlmhxChYwGd
b928LOTxbqYsizX5Mpdoo9dZ+yKZF3+ZsftIDDCVpGTWF7UGq+KvXn3PrLBgk9P9Bxi1ZyNkYatM
txerdgElBbaxsQwkOHI4uj9QPFq30Zwu4OZO7vYfx7LnBN5fP85T9qwy2BLCQM5tVcIJAST9xIJm
QwBB1smIAAAAAAAA
------=_NextPart_000_007B_01C7E502.8FF4AA20--
討論串 (同標題文章)
完整討論串 (本文為第 1 之 8 篇)：