Több mint 7 éves, rendkívül kritikus biztonsági hibát javítottak a Xen hypervisor-ban

 ( trey | 2015. november 1., vasárnap - 11:20 )

A Xen Security Team a napokban bejelentette, hogy a Xen hypervisor paravirtualizált virtuális gépek (PV VMs) memóriavirtualizációját kezelő kódjában kritikus biztonsági hibát találtak (XSA-148). A rosszindulatú paravirtualizált (PV) guest adminisztrátorok a hiba sikeres kihasználása révén emelhetik privilégiumszintjüket és átvehetik az irányítást az egész rendszer felett. A hiba körülbelül 7 évvel ezelőtt, a Citrix alkalmazásában álló Keir Fraser "x86: PV support for hugepages" commit-je nyomán mutatkozott be. A sebezhetőség a Xen 3.4 és újabb verziókat érinti. Csak az x86 rendszerek sebezhetők, az ARM rendszerek nem. Csak a paravirtualizált guest rendszerek adminisztrátorai tudják kihasználni a sebezhetőséget. Mind a 32 bites, mind a 64 bites PV guest-ek képesek a hibát kihasználni.

A biztonságot mindenek felett szem előtt tartó, Xen-re építkező Qubes OS projekt is figyelmeztetőt (QSB-022-2015) adott ki a sebezhetőséggel kapcsolatban, amelyben néhány keresetlen szót ejtettek a Xen projekt fejlesztési, programozási irányelveivel kapcsolatban.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Ez jó eséllyel azt jelenti, hogy a Qubes OS a Xen miatt a kezdetektől fogva lyukas volt.

--
trey @ gépház

Nyugi, szinte biztos, hogy a javítás után is lyukas marad.. :)

Hajlamosak vagyunk azt hinni, hogy ami virtuális gépben fut, az akkora kárt nem okozhat, pedig dehogynem, ha a hypervisor lyukas. Kis bugok mindig lesznek, de hogy egy kis bug elvezessen a teljes rendszer kompromittálásáig, az rendszerszintű hiányosság. Szerintem teljesen jogos elvárás, hogy megfelelően álljanak hozzá a fejlesztők, pl. néhány száz/ezer assert-tel meg kellene szórni a kódot.

--

Sponsored by NSA.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

Az a helyzet, hogy az assert loszart nem ér. Formális validációra lenne szükség.

Amazonnál már egy ideje TLA+-szal szűrnek ki bugokat, a nagy gond az, hogy ők viszont csak modellt validálnak vele, nem konkrét implementációt.

Majd egyszer elérünk oda is.

Ez a formális validáció nekem mítosz, még nem nagyon láttam működni, pedig tanultam róla, és tényleg jó lenne. De valahol el kell kezdeni, ennek a legkönnyebb módja pár assert lenne, szerintem a jelenlegi bugot is megtalálhatták volna vele. Aztán a következő lépés a jól megírt unit teszt, mert gondolom, azt se vitték túlzásba.

--

Az assert a gyakorlatbn nem lesz formális. Ott nem teljes állapotteret validálsz, hanem bizonyos feltételek teljesülését. Ha kifelejtesz egy feltételt, nem fogod észrevenni, és azt gondolod, helyes a kód. Tipikus példa erre a sima add(a,b) = a+b függvény esetén az "if a>0 and b>0 then a+b>0" jellegű assert, ami elsőre butaságnak tűnik, de az integer overflowtól megvéd.

Továbbá ha van állapot (mert mondjuk objektumorientáltan strukturáltad a programod), netán még shared state-ed (több thread, stb.) akkor az asszertjeid teljesen fölöslegesnek is mondhatók, hiszen az assert az időközbeni állapotváltozástól nem fog tudni megvédeni. Ezekre mondjuk a pure functional megközelítés megoldást nyújt.

A QuickCheck-szerű teszt toolok sokat segítenek a validációban, mivel néhány unit test helyett függvényenként több millió példára validálják, de hát a QuickCheck modelt is valakinek meg kell írnia.

Az amazonos paper igen tanulságos, eléggé kételkedve olvastam (mivel tudom, hogy a TLA-val nem fogod te a kis C kódocskádat validálgatni), és le is lövöm a poént, a végére kiderül: model validációról beszéltek végig. A jó hír azonban, hogy így is a gyakorlatban használhatónak találták, mivel több bugjukat megtalálták vele, még mielőtt high revenue losst okozott volna :-)

Szóval ha 2015-ben azt írod, hogy nem nagyon láttad még működni, az azt jelenti, hogy nem néztél elég jól körül. A Microsoft Researchben nagyon kutatják a területet (lásd F#-ban levő tök jó contract-related kiegészítések), valószínűleg alkalmazzák is. Másik nagy példa pedig az Amazon. Aztán egyéb kísérleti példákon is látható, hogy működik a dolog (seL4) - mindössze még nem elég elterjedt ahhoz, hogy a php-pistikék is használják. De ha ügyes vagy, megelőzheted azt a szintet ;-)

Nem az volt a "hír" régen, hogy a VM-eket a "processzor futtatja", szeparáltan? Most mégis kiderül, h van benne értelmező, interpreter, ami kompromittálható?

Hányan tesznek VirtualBox-et production környezetbe...abban mi lehet.

"Hányan tesznek VirtualBox-et production környezetbe...abban mi lehet."

dafuq? remélem nem sokan tesznek :D

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Pedig ha tudnád, jópárral találkoztam már.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Öröm látni, hogy a git blame is milyen jól működik :)

-

Pár okos kutató/fejlesztő elmondta már, hogy a virtualizáció nem biztonságtechnikai eszköz.

De az infra(struktúra) leírásánál többen elhitték/tük, hogy abszolút a szeparáció. Most meg kiderül, hogy egy C64 Turbonak felel meg, mint interpreter "load 8,1"

Nem interpreter van benne (kivéve ha nem a cpu futtatja, mint pl. qemu-nál ahol más architektúrát is tudsz emulálni). Nem is itt van a kompromittálhatóság lehetősége, hanem pl. driver illesztőknél (is, fixme). Feljebb tud nyúlni a felsőbb rétegekbe. Hiba bármilyen szoftverben lehet és van is.

De az infra(struktúra) leírásánál többen elhitték/tük, hogy abszolút a szeparáció.

Aki ezt hitte, az meg is érdemli.

Soha senki nem mondta, hogy abszolut szeparáció, sőt minden esetben egyértelmű volt, hogy minimum a CPU és a RAM KÖZÖS. Tehát, ha van kiút akkor ezeken keresztül van. Hát most meg is találták.

Az azért egy érdekesebb kérdés, hogy direkt lett-e ez a bug vagy véletlenül.
(mondjuk szerintem olyan, hogy véletlen egyszerűen nincs)

De azért én még nem írnám ezt ennyire le, ugyanis ettől függetlenül még mindig nincs ennél jobb megoldás jelenleg. Mert az ugye megvan, hogy pl VMware és/vagy Hyper-V esetében egy ilyen 'bug' várhatóan soha nem derülne ki... De attól még létezhet.

--
zrubi.hu

Jó, hát valami csontot dobnak, amit "jóváhagynak" felülről.. ;)