Re: ESX Vmware Physically connected to different segments

From: David M. Zendzian (dmz@dmzs.com)
Date: Mon Jan 28 2008 - 16:07:18 EST


I agree with you, the canary is definitely looking pale; however I won't
stop using bind because someone keeps posting theories on how to hack
it. I have to live with it and I have to have virtual hosts that share
customers....

Plus this is another argument for open-source. If something like this is
found, I'm optimistic that someone will provide a xen patch (if not then
we watch for people taking advantage of that exploit, maybe installing
KLM in guest systems, no windows guests, etc).

It's not a good world, but we gotta live w/it :)

David

Kurt Buff wrote:
> 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