Sun VirtualBox host reboot PoC

 ( Nyosigomboc | 2009. augusztus 2., vasárnap - 10:30 )

A minap a milw0rm-on felbukkant egy proof-of-concept exploit. A Virtualbox guest-en futtatott kód alkalmas a host összeomlasztására (a host rebootol). Több különböző guest operációs rendszeren kipróbálták (Windows XP, Windows 7 RC, Ubuntu 9.04).

Az egyelőre nem világos, hogy tetszőleges kódfuttatásra kihasználható-e a bug. A víruskeresőkkel foglalkozó szakemberek sokszor elemzik a kártevőket virtuális gépen, ennek megnehezítésére mindenesetre jól jöhet a programhiba a malware készítői számára.

A PoC itt található.

(A hír nem szól arról, hogy Windows hoston működik-e. Esetleg valaki kipróbálhatná.)

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ő.

hahaha tessek csak virtualizalni, mert az secure.

OpenBSD-vel nem müxik az exploit?

openbsd-re nincs vbox
___
info

De guest-ként azért futhat...

de mivel a virtualizacio koztudottan biztonsagi kockazatokat rejt (lasd pl. cikk), nem ajanljak virtualizacio hasznalatat.
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

ez a hostot induja ujra, ergo ami futtatja a vboxot

If sysenter instruction is executed on the guest
OS the host machine will reboot.

akkor hol itt a problema openbsd alatt?
___
info

Nyert.
A kódot nem futottam át. Nagyon hosszú volt :D
Tehát OpenBSD-vel is elszáll. :DD

Guest-kent plan9 is futhat, azon is mukodne, ebbol a szempontbol tokmindegy.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Az nem biztos, legalábbis nekem nem sikerült Plan 9-et feltelepítenem rá, a grafikus módra váltás nem sikerült. Sokféle összeállításon próbálkoztam már Plan 9-el, szerintem még egy abakuszon is képes lenne VGA képernyőmódba váltani, szóval inkább a VirtualBox-ot hibáztatnám.

----
Írtam egy fizikakönyvet: http://www.scribd.com/bvalek2 | Plan 9 felhasználó

... mondjak ezt azok, akiknel ez csak egy "reliability fix"-et erne. :)

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

mert az is :)

Kellenek ezek a hibák, hogy tudjuk mivel alátámasztani ennek az ellenkezőjét. :)


suckIT szopás minden nap! HUPwnie awards

a virtualizacio maga jo gondolat, nem az elv a rossz, hanem arrol van szo, hogy van egy bug a virtualbox-ban. Ennyi erovel mondhatnad azt is - legyen pl. egy bug az openssh-ban - hogy a remote access kaka....

SPAMtelenul - POP3 spamszuro szolgaltatas

Nem ezzel van baj, hanem azokkal, akik szentül meg vannak győződve arról, hogy a virtualizáció mindenképpen biztonságos.


suckIT szopás minden nap! HUPwnie awards

Momentán ezt senki nem állította (itt).
Másrészt a VBOX ugye nem egy enterspájz gréd cucc.

Én sem állítottam, hogy itt hallottam. Szerencsére enterspájz gréd cuccban is van már mutogatható hiba.


suckIT szopás minden nap! HUPwnie awards

szerintem Te is tudod, hogy a virtualizaciot nem ezert tolja a legtobb ember. jo, benne van a top5 reasonsben. :)

Attól függ mit mivel hasonlítasz össze. Ha azt nézzük, hogy van két szolgáltatás, aminek biztonsági szempontból szeparáltnak kell lennie, akkor a három opciód van:
a) egy OS kernel felett futnak
b) egy hoston virtualizálva két külön guest kernel felett futnak
c) fizikailag két külön gépen futnak

Nyilvánvaló, hogy a a) és b) kevésbé biztonságos, mint a c), de azért óvatosan az is kijelenthető, hogy a) kevésbé biztonságos, mint b). Összetettsége miatt egy hagyományos OS-en lokális exploitálásra jellemzően elég sok lehetőség van. Nem csak a kernel local root exploitokra gondolok, hanem a rosszul megírt/konfigurált library/alkalmazásokon át egészen a felhasználó által hibásan beállított jogosultságokig. Platform virtualizációnál a hibalehetőségek száma lényegesen kissebb, ráadásul kevés dolgot ronthat el a végfelhasználó. Tehát a platform virtualizáció igenis használható a biztonság növelésére, ha a) -> b) irányba mész, de nyilván kockázattal jár, ha c) -> b) irányba történik.

Amúgy általában a periféria backendek szoktak hibaforrások lenni, a virtualbox mostani bugja valami elég triviális hibának néz ki, sysenter-re azért szerintem illene lennie legalább egy regression tesztnek.
---
Linux is bad juju.

Ez egyértelmű, de én konkrétan olyan miatt írtam, amiket, aki szerint b==c.


suckIT szopás minden nap! HUPwnie awards

nem azert virtualizalnak, mert biztonsagos, hanem mert olcso :p

--
When in doubt, use brute force.

Ahol rendesen virtualizálnak ott nem olcsó. Ahol virtualizálgatnak, ott lehet :)

--
trey @ gépház

Nem biztonságos, nem olcsó. A végén még kiderül, hogy a teljesítmény sem jó.
Rohadt marketingesek.


suckIT szopás minden nap! HUPwnie awards

jah, atvertek :(

--
When in doubt, use brute force.

Kurvara nem olcso es csak pocsekolod az erforossakot. A marketing szoveg hogy jeee 20 eves binarisokat is tudsz futtatni az uj servereden kulon virtualis gepben pedig bullshit. Ehhez nem kell virtualis gep, csak egy kis agy.

ahahahahahah
"pocsekolod" ez tetszett a legjobban

miert nem? :) 0 eroforras, 0 overhead futtatni 1 virtualis gepet? nem azt mondom hogy teszteleshez nem jo a virtualizacio mert akkor hazudnek, mi is hasznaljuk, de sajnos piedesztara van emelve az egesz

termeszetesen nem nulla az overhead. de ha megnezek egy ceget, latok mondjuk 5 desktop pct "szerverkent", aminek a kihasznalasa par szazalek.

ilyenkor nem jobb egy fizikai vasra migralni? az sem lesz kitolva. karbantartani meg konnyebb. igaz, ha nincs meg 1 gep, es nem tud live migralni,
akkor egy hw csere miatt az egesz infrastruktura all, de hat egy geppel nem szabad csinalni :)

Akkor lehet, ha az infrastruktura elviseli a hw problema miatti allast. Nem minden feladatra kell sokkilences rendelkezesre allas.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ha úgy kezdem, hogy egy normális SAN alsó hangon több milliós nagyságrend, akkor nem olcsó. Persze el lehet virtualizál_gat_ni SAN nélkül is. Erre céloztam. Egyébként nem rossz dolog a virtualizáció, de egy kicsit szerintem is túl van lihegve. Az elmúlt években nem voltam olyan rendezvényen, konferencián, stb. ahol ne az lett volna az üzenet, hogy "ha nem virtualizálsz, akkor egy utolsó senki vagy". És ennek köszönhetően lehet az, hogy jön az ügyfél, hogy __egy darab__ olyan gépre (local két szem diszkre) akarja az egész vállalatot bízni virtualizációval (mert ezt hallotta, ezt olvasta a $FOO Magazinban), amit én egy jó desktop-nak sem mondanék.

--
trey @ gépház

Virtualizáljunk rögtön SAN-t és hálózatot is hozzá. Már csak az embereket kell virtualizálni, és kész is vagyunk. Tényleg bármit el lehet adni ezzel a szóval pár embernek.

Erre leginkább a minicégeknek van szükségük, akik még hisznek a HA clusterekben, és nincs pénzük (elkötelezettségük) arra, hogy megfizessék a tudást, ami kivezeti őket a 20. század süppedős mocsarából. ;)

(jó, van néhány hely, ahol tényleg jól jön)


suckIT szopás minden nap! HUPwnie awards

Ja, olyan minicegeknek, mint pl. a MOL. :)

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Maradi szakemberek dolgoznak ott, az a baj. A MOL-nál dolgozók 93,4%-a Jock Ewingtól tanulta az olajszakmát, az pedig már nem ma volt!


suckIT szopás minden nap! HUPwnie awards

Jol alatamasztott, mely szakmai erveles, a HUP vedjegye.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

VULNERABILITY INFORMATION

Remotely exploitable: no
Locally exploitable: yes

Ezt érdemes lenne hozzáírni a poszthoz.

a hiba lényegéből adódóan ez nyilvánvaló...
Ha a futtatott guest valamilyen szinten elérhető távolról, onnantól pedig remote.

Nem, mert az "ssh-n at futtatom" az nem a remote exploit definicioja IMHO.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

úgy értettem, hogy definició szerint nagyon is local (ez a nyilvánvaló) csak a hiba jellegéből adódóan nagyon könnyen remote-tá válhat. (nem ez a hiba, hanem a veszély amit ez okoz)

"csak a hiba jellegéből adódóan nagyon könnyen remote-tá válhat"

Csak annyira "nagyon konnyen", mint akarmi mas.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Valamit nem ertettel meg. Ha a local exploit-ot egy remote exploit-on keresztul lefuttatva kihasznalod, attol meg a local exploit nem lesz remote, local marad.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Amihez jo hozzatenni, hogy remote (is) kihasznalhato.....

SPAMtelenul - POP3 spamszuro szolgaltatas

te nem érted, de mindegy, valójában ugyanarról beszélünk. Definició szerint local, jellege miatt mégis könnyen kihasználhatóvá válhat távolról, mig a legtöbb local exploit távolról sokkal nehezebben használható ki, pl egy másik hiba kell hozzá. Ehhez viszont nem kell másik hiba, bizonyos esetekben elég ha a guest távolról elérhető. (és igen, ettől még nem kell remote-nak nevezni)

"mig a legtöbb local exploit távolról sokkal nehezebben használható ki, pl egy másik hiba kell hozzá"

Mondj egy peldat.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

nekem nem rebootol.
host: 64bit linux,
guest: xp pro,
vbox version: 3.0.2-r49928.

a zikszpé rendesen kiírja a sysenter-re, hogy "alma.exe has encountered a problem and needs to close."

"BITS 32"?