lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 25 Aug 2007 13:30:30 -0400
From: "Ken Kousky" <>
To: "'Arthur Corliss'" <>
Cc: <>
Subject: RE: VMWare poor guest isolation design

I'm trying to understand how the vm actually prevents the buffer overflow
from injecting code that has direct hardware control? It seems that the code
injected into memory should be truly "arbitrary code" based on the physical

Are there any good papers that explain how the vm shields against buffer


-----Original Message-----
From: Arthur Corliss [] 
Sent: Friday, August 24, 2007 5:45 PM
To: Ken Kousky
Subject: RE: VMWare poor guest isolation design

On Fri, 24 Aug 2007, Ken Kousky wrote:

> This may be far off course but with all the discussions of VMWare  as a
> sandbox that has broad security value it seems we have to pay attention to
> the assumptions. IF the virtual machine is operating properly, it can
> provide a level of sandboxing and restrict session privileges for that
> instance of the machine. However, the most common exploit in software
> continues to be memory leakages or buffer overflows.
> It seems to me that the code that can be injected through the most common
> attack vector (buffer overflows) executes with full privileges of the real
> hosting machine, there would be little benefit to the virtualization. Am I
> missing something here?
> Is there a way that the arbitrary code injected through a buffer overflow
> can be constrained in the logical machine? It seems to me the VM can't
> provide this protection???

VMs can do just that, isolate the damage to the vm, with no impact to the
host.  This discussion never addressed that, though, it was focused on the
premise that vms should be protected from the host operating system, which
is exceedingly impractical.  The host was never in danger from the
techniques discussed here.

I think you may be referring to sandboxes like chroot & jails which are not
quite as effective at isolating processes as the vm route.  They have a hell
of a lot less overhead, though.

 	--Arthur Corliss
 	  Live Free or Die

Powered by blists - more mailing lists