Re: ESX Vmware Physically connected to different segments

From: Kurt Buff (kurt.buff@gmail.com)
Date: Mon Jan 28 2008 - 15:52:01 EST


There are already exploits in the wild that detect if they are running
in a virtualized environment and abort themselves. I consider that the
canary in the coal mine.

While this:

http://securitydot.net/xpl/exploits/vulnerabilities/articles/1390/exploit.html

isn't about ESX, it's certainly on the right road, I believe.

Kurt

On Jan 28, 2008 12:32 PM, David M. Zendzian <dmz@dmzs.com> wrote:
> Yes it does make you think twice when considering such a design, however
> I am not familiar with exploits at a guest domain that would effect the
> host specifically. While yes in 'theory' there could be some kernel hook
> that could allow a guest to access the host server, and I hate to be in
> a situation when one arrives; however, the same argument also applies to
> shared virtual web hosts, but only the largest companies have dedicated
> hosts for every domain, there will always be sharing happening which is
> why virtual environments are growing in popularity.
>
> Would it not be better to examine the hooks in systems that allow
> communication / buffers / etc in virtual environments and help ensure
> that they are done correctly? I know this is not really possible with
> VMWare, but with Xen & other systems where the code is available the
> issues can at least be investigated.
>
> Now if someone has code (links/docs/etc) available the detail attacks on
> guests effecting hosts (DOS not included, exploits taking control of
> services of a host from a guest, or accessing network or resources not
> setup for that guest), then please post them to the list so we can
> discuss the issues and how to address them.
>
> These same questions might also be applied to VLANs or other types of
> virtualization techniques that allow for greater use of the devices we
> have available. While there are fun ways to attack network vlans to
> access security domains outside of configured settings, it is the
> disclosure of these techniques that allowed for providers to secure the
> tools to a point where I know of no business I've ever worked with have
> dedicated network devices for every network. While I have seen different
> equipment on "DMZ vs Internal" networks, most still use VLAN security to
> segment those as well (it's a $ thing & usually a complexity thing, more
> parts means more people to manage, understand, change w/ out breaking, etc).
>
> I believe there are ways of deploying virtual technology that may not
> prevent the theoretical attack, at least provide protection against the
> common attacks and provide for a viable solution for the small business'
> I work with.
>
> The only way to be secure is to unplug, the rest of us have to work for
> a living :)
>
> David
>
>
> Kurt Buff wrote:
> > Even if everything is configured properly, mixing security domains in
> > a virtual hosting is a capital mistake.
> >
> > That's because the underlying host is also vulnerable, and attacks
> > against a guest OS in an untrusted domain can be leveraged against the
> > host, and from there *all* guest OSes are toast, or near to it.
> >
> > Don't do it, ever.
> >
> > Kurt
> >
> > On Jan 28, 2008 5:08 AM, Loupe, Jeffrey J <JLoupe@whitneybank.com> wrote:
> >
> >> If everything is setup properly this configuration should be secure. The
> >> problem comes with misconfiguration. It's exceedingly easy for a
> >> careless admin to connect a vNic to the wrong vSwitch and allow traffic
> >> meant for the DMZ onto the trusted network. In general we disallow this
> >> practice unless only one or two trusted admins have control of the box.
> >> Even then, we audit the configuration frequently.
> >>
> >> -J
> >>
> >> ________________________________________________________________
> >>
> >> Confidentiality Notice:
> >>
> >> This E-Mail transmission (and/or the documents accompanying it)
> >> may contain information belonging to the sender which is
> >> confidential, privileged and/or exempt from disclosure under
> >> applicable law. The information is intended only for the use
> >> of the individual(s) or entity named above. If you are not
> >> the intended recipient, you are hereby notified that any
> >> disclosure, copying, distribution or the taking of any action
> >> in reliance on the contents of this information is strictly
> >> prohibited. If you have received this E-Mail transmission
> >> in error, please immediately notify us by return E-Mail or
> >> telephone to arrange for return of its contents including any
> >> documents.
> >>
> >>
> >
>
> > ------------------------------------------------------------------------
> > This list is sponsored by: Cenzic
> >
> > Need to secure your web apps NOW?
> > Cenzic finds more, "real" vulnerabilities fast.
> > Click to try it, buy it or download a solution FREE today!
> >
> > http://www.cenzic.com/downloads
> > ------------------------------------------------------------------------
> >
> >
> >
>
>

------------------------------------------------------------------------
This list is sponsored by: Cenzic

Need to secure your web apps NOW?
Cenzic finds more, "real" vulnerabilities fast.
Click to try it, buy it or download a solution FREE today!

http://www.cenzic.com/downloads
------------------------------------------------------------------------



This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:58:22 EDT