|
BugTraq
VMWare poor guest isolation design Aug 23 2007 03:22AM M. Burnett (mb xato net) (2 replies) Re: VMWare poor guest isolation design Aug 23 2007 04:49PM Arthur Corliss (corliss digitalmages com) (6 replies) Re: VMWare poor guest isolation design Aug 24 2007 01:06AM Jonathan Yu (jonathan i yu gmail com) (1 replies) Re: VMWare poor guest isolation design Aug 24 2007 08:13AM Arthur Corliss (corliss digitalmages com) (2 replies) More on VMWare poor guest isolation design Aug 25 2007 01:29AM M. Burnett (mb xato net) (2 replies) Re: More on VMWare poor guest isolation design Aug 27 2007 02:37PM wietse porcupine org (Wietse Venema) Re: More on VMWare poor guest isolation design Aug 25 2007 07:05PM Tim Newsham (newsham lava net) (1 replies) RE: VMWare poor guest isolation design Aug 23 2007 10:40PM James C. Slora Jr. (james slora phra com) RE: VMWare poor guest isolation design Aug 23 2007 08:46PM William Holmberg (wholmberg amdpi com) (1 replies) RE: VMWare poor guest isolation design Aug 24 2007 07:16AM Arthur Corliss (corliss digitalmages com) RE: VMWare poor guest isolation design Aug 23 2007 08:30PM M. Burnett (mb xato net) (1 replies) RE: VMWare poor guest isolation design Aug 24 2007 07:50AM Arthur Corliss (corliss digitalmages com) |
|
Privacy Statement |
discussion I had on this same list almost ten years ago trying to explain to
Microsoft why a vulnerability that discloses physical paths is a big enough
deal to bother patching. Their argument was that they couldn't see the risk
of disclosing a physical path, and if someone could do something with that
path then they could probably discover the path in the first place. My
argument was that it really doesn't matter what the current risks might be,
that's really not the point, let's just fix it anyway. It turns out later
there were a number of IIS issues where people could execute or access
files, but they needed to know the physical path first.
I think some of you are overanalyzing this issue. I am well aware that there
are other ways to accomplish the same thing in many instances, I am not
saying I have introduced a spectacular new attack vector. I would categorize
this threat standing on its own as medium to low, depending on your
environment. But the fact is that this thing bypasses normal OS security
mechanisms and we simply cannot imagine how that might be used by an
attacker in the future. Some of you keep trying to point out that owning the
host always means owning the guests, but that isn't always the case,
especially if you are not a full administrator on the host machine.
I know that for a lot of years people have been saying that once someone can
access the physical box, there's nothing more you can do. Well, that's just
not true anymore. You very well can protect a physical machine and you
should be able to protect a virtual guest from its host. There's no way a
non-admin user is going to be able to modify the RAM of a vm. And in Windows
Vista, if not already blocked, even as an administrator I would have to
explicitly allow a worm to access the RAM or disk of a virtual machine. No
worm is going to access a vm's resources without a UAC prompt coming up.
The argument that owning a physical machine automatically means game over
just isn't true. We should be able to say the same thing about a VM.
Mark
> -----Original Message-----
> From: Tim Newsham [mailto:newsham (at) lava (dot) net [email concealed]]
> Sent: Saturday, August 25, 2007 1:05 PM
> To: M. Burnett
> Cc: 'Arthur Corliss'; 'Jonathan Yu'; bugtraq (at) securityfocus (dot) com [email concealed]
> Subject: Re: More on VMWare poor guest isolation design
>
> > 2. This issue is not about a user on the host compromising a virtual
> guest.
> > It is about a *non-privileged* user on the host being logged in to
> guest
> > machines as an administrator, and a worm--running in the context of
> that
> > non-privileged user on the host--being able to access the admin-level
> > context of the guest machines without knowing those administrator
> > credentials. Also remember that since I am talking about a non-
> privileged
> > user on the host, there will be limits on what this user could do to
> > accomplish some of the other attacks mentioned.
>
> Your position seems to be that an easy automated scripting interface is
> a
> lot more dangerous than a slightly harder indirect attack method. The
> truth is that they are both scriptable and reliable. Techniques for
> attacking virtual machines from the host are certainly no harder to
> code
> than the average remote exploit that worms used to propogate. Do you
> really think a worm writer who wants to compromise VMWare guests would
> take advantage of a scripting interface but shy away from the task if
> he
> had to write custom code to break into the guest?
>
> > 4. This is also not so much about this specific issue at hand--we can
> easily
> > block this--but also looking at the bigger picture of establishing
> best
> > practices for dealing with the guest/host relationship.
>
> Here's a best practice: Don't assume that guests are protected from
> software running on the host system.
>
> > As a side note, I specialize in hardening Windows so all of these
> systems
> > have been hardened with my own hardening script that is quite
> extreme. These
> > are by no means weak targets.
>
> A (virtual) machine where attackers can arbitrarily read and write
> the memory, the disk and even alter devices is going to be a soft
> target.
>
> The physical analogy that someone brought up earlier works well here.
> Would you consider your machine locked down if someone could open
> your computer case, yank the hard drive and attach new devices to the
> system at will? Well, with a virtual machine they can do that while
> the machine is running.
>
> > Mark Burnett
> > http://xato.net
>
> Tim Newsham
> http://www.thenewsh.com/~newsham/
0? *?H?÷
?0?10 +0? *?H?÷
? 0?0? cß¡VDzò}ée¾{*×?&0
*?H?÷
0b10 UZA1%0#U
Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CA0
070509163711Z
080508163711Z0=10UThawte Freemail Member10 *?H?÷
mb (at) xato (dot) net0 [email concealed]?0
*?H?÷
0?ª%!{;ëÓÈ<0??~C8É?õÔ_?ÆS_¹ñlµ?å·Èøä2xÉfº=hTV11 hY:Ü?n
jzÒç?~\¼ÅÍzZ9VÖ?Øçê'qÆò´æ½¡cq??
ÝO !m?DhVÑe?OòN8¡å?#¡?Ê {cE?£y0w0Uÿ?0 `?H?øB 0,+e#0!0083zwvGTz6p7wGjCksTJZA0U0
mb (at) xato (dot) net0 [email concealed]Uÿ00
*?H?÷
2ú¯÷$?52È?ÄH6/øÀ@A-|?¥æ ¾?YýÊu?¼ÂÛÅy?Íu5Ù©,ùM[?Ü×-?Û)S¼l¾?zá6;ô7ÐT·9?Þ»¡ty¯²½/i~_
í§Å-í [YZP÷|ª??¼=üsh??pÛv0?-0?? 0
*?H?÷
0Ñ10 UZA10UWestern Cape10U Cape Town10U
Thawte Consulting1(0&UCertification Services Division1$0"UThawte Personal Freemail CA1+0) *?H?÷
personal-freemail (at) thawte (dot) com0 [email concealed]
960101000000Z
201231235959Z0Ñ10 UZA10UWestern Cape10U Cape Town10U
Thawte Consulting1(0&UCertification Services Division1$0"UThawte Personal Freemail CA1+0) *?H?÷
personal-freemail (at) thawte (dot) com0 [email concealed]?0
*?H?÷
0?Ôi×Ô°?d[qéGØQ¶êr?°?^}-
{ß?%u(t:B,c'??{Kï~??ê£Ý¹Î?dÂnD¬|æèMq@8¦£?xöù??^êÀ^vëÙ£]nz|¥KU)??&Õj»8$j?DZڣ??ýyÛåZĹ£00Uÿ0ÿ0
*?H?÷
Çì?~Nøõ?¥gb*¤ðM`Ðo`Xa¬&»R5\Ï0û¨J??bB#?ôºd?¬G)ß?^Òl`q\¢¬Üy
ãçnGµ
(èä?ýô¦Ù|±øÜ_#& ??sÐÞC©?%òæ?/Êþ¦«?u?ÝQ?käøÑÎw¢0??0?¨
0
*?H?÷
0Ñ10 UZA10UWestern Cape10U Cape Town10U
Thawte Consulting1(0&UCertification Services Division1$0"UThawte Personal Freemail CA1+0) *?H?÷
personal-freemail (at) thawte (dot) com0 [email concealed]
030717000000Z
130716235959Z0b10 UZA1%0#U
Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CA0?0
*?H?÷
0?Ħ<UsUûN¹Ê?ZhÀupßéÿ£ì½Íõ[òv½:aò¿QÎÔåP
0×cZ,?p?ÝÉð+?Zª?qV˯<çñ?6$*Ï+Õó?w=¾+þ»>¿@?d×§¦»?eÑÅ*T?H§¶Ñ<
a@dr`·û£?0?0Uÿ0ÿ0CU<0:08 6 4?2http://crl.tha
wte.com/ThawtePersonalFreemailCA.crl0U0)U"0 ¤010UPrivateLabel2-1380
*?H?÷
H?ÑP?ê.Ì
£f¬g¯¬¾Â¡C??L!¸ø6ª-?6/ÀôP ?p<ýáabÃÙ:~?±?Å?t?%P?bÇÛ'qW%Ý©?9?? Oe_?Ú÷÷?ÖÆN®öê4å[5MwãV!x?Ü!5Þ$±ÓFÿ]_eO1?¢0??0v0b10 UZA1%0#U
Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CAcß¡VDzò}ée¾{*×?&0 + ?0 *?H?÷
1 *?H?÷
0 *?H?÷
1
070827175145Z0# *?H?÷
1??à~ª£Y¡³DXÌr0$ *?H?÷
100+0
*?H?÷
0
*?H?÷
?2è«å?Úz$g§?/T?â?ûÜ?E×
¾ó?v9üzá½XX²Øf}`Õa(Eçqæ?ÝAÂðGJ(2º¿p)?É!??ÔªT%?R3.§ÙP:mû?ÚÄÖ ¼3q?«/º;~¦?<µBüýéa?Å«=X?m?{ù¤Õ
[ reply ]