Privilégium szint emelésre ad lehetőséget a VMware CPU emulációjának hibája

Bug

A VMware termékek hardver szolgáltatásokat emulálnak, megteremtve a lehetőségét a vendég (guest) operációs rendszerek futtatásának. Egy, a CPU hardver emulációban levő hiba lehetővé teszi a virtuális CPU számára, hogy az helytelenül kezelje a "Trap" flag-et. A hiba sikeres kihasználása privilégium szint emelésre adhat lehetőséget a vendég operációs rendszeren.

A támadónak felhasználói fiókkal és alkalmazás futtatási lehetőséggel kell rendelkeznie a vendég OS-en a hiba kihasználásához. A VMware köszönetett mondott Derek Soeder-nek a hiba jelentéséért.

Az érintett VMware termékek listája elérhető a bejelentésben, amely egy másik, "directory traversal" típusú sebezhetőségről is említést tesz.

( kohinoor | 2008. 11. 08., szo – 20:16 )

attol tartok, ez csak a jeghegy csucsa :( ujabb leallasokat kell betervezni a ritualis kornyezet patchelesere is, a vegen mar tobbet all a rendszer, mint amennyit megy :)

Azért ez nem 100%. Ha CPU emuláció másképp kezd működni, akkor már nem biztos, hogy teljesen csereszabatosak lesznek a host gépek. Pl. különböző cpu architektúrájú (P4 vs. Core2) gépek között a live migráció nem kifejezetten zökkenőmentes, csak akkor működik, ha nagyon durván lebutítod a virtuális CPU feature-jeit. Simán lehet, hogy most sem lehet megúszni a guest restartot. Da majd jövő héten, ha lesz időm foglalkozni vele, akkor majd kiderül, hogy okoz-e bajt.
---
Linux is bad juju.

Nem próbáltam ki, de meglepne, ha nem működne a VMotion: a VM gyakorlatilag virtuális hardver definíció, nem implementáció. Ezenkívül egy futó VM-nek van egy állapota (RAM tartalom).

A flaw in the CPU hardware emulation might allow the virtual CPU to incorrectly handle the Trap flag.

Azaz magával a végrehajtással van gond (ami az éppen futtató ESX által történik), nem azzal, ami a VM memóriájában van.

Azaz magával a végrehajtással van gond (ami az éppen futtató ESX által történik), nem azzal, ami a VM memóriájában van.
Ettől éppenhogy lehet. A guest OS-ek nem igazán vannak felkészítve arra, hogy futás közben az alatta lévő CPU feature flagjei vagy a szoftveres workaroundot igénylő bugjai, mikrokódja, stb. csak úgy hirtelen megváltozzanak. Restart után általában elviselnek más CPU architektúrát is, ez szerencsére ma már többnyire a windows-okra is igaz. De restart nélkül nem. Ezért is akkora szenzáció ez a hír: http://hup.hu/cikkek/20081110/kulonbozo_gyartok_cpu_platformjai_kozti_live_migration-t_demozott_a_red_hat_es_az_amd
Ugye a VMware alatt egy úgy lehet megoldani, hogy szándékosan lemaszkolunk egy csomó CPU flaget, ez valahol az edit vm settings/options/advanced alatt van elásva.

Ettől függetlenül én is valószinűsítem, hogy a trap fix esetén nincs olyan szemantikai változás, ami miatt elhalna a guest, de az elvi lehetősége szerintem megvan.
---
Linux is bad juju.

Ha megnézed a javítás adatlapját, nem írja azt, hogy nem működne a VMotion (ha nem működne, valószínűleg jó nagy viszhangja lenne, lásd augusztus 12.), azaz a technológia ismét jó szolgálatot tehet.

Ami az Intel és AMD közötti Live Migrationt illeti: nem teljesen értem a cikket, kicsit pongyola, nagyon meglepne ha VMware-es ilyet mondott volna (az egyik idézett cikk alapján Inteles mondta - ez kevésbé meglepő), hiszen a VMware tudtommal kifejezetten azon mesterkedik, hogy az Intel és AMD közötti VMotion működjön *támogatható* módon.
Ha valakinek van AMD-s ESX-e az Adatparkban, játszhatunk :-)