Lek in virtuele drive maakt aanval op hostsysteem vm's mogelijk

De firma CrowdStrike heeft een kwetsbaarheid in de virtual floppy disk controller van QEMU ontdekt. Dit onderdeel wordt onder andere gebruikt door Xen en KVM. Het gat maakt het mogelijk om toegang te krijgen tot het hostsysteem waar virtuele machines bovenop draaien.

Het beveiligingsgat, dat Venom is gedoopt, is ontdekt in de virtuele-floppycontroller. Deze wordt gebruikt door diverse hypervisors, waaronder Xen, KVM en de native QEMU-client. De hypervisors van Hyper-V van Microsoft, VMware en Bochs zijn niet kwetsbaar.

Volgens CrowdStrike bevat QEMU's gevirtualiseerde floppydrivecontroller een bug als er bepaalde commando's worden verstuurd. Hierdoor ontstaat een bufferoverflow en kan er kwaadaardige code in de hypervisor worden uitgevoerd. Het gevolg is dat een aanvaller potentieel andere virtuele machines of het onderliggende besturingssysteem kan aanvallen.

Om de bug in de virtuele-floppycontroller te misbruiken, dient een aanvaller of de gebruikte malware wel over rootrechten of administrator-toegang te beschikken voor het betreffende virtuele gastsysteem. Verder zijn alle onderliggende hostbesturingssystemen waarop de hypervisor draait kwetsbaar voor het Venom-beveiligingsgat.

De bug zou al sinds 2004 in de broncode van QEMU aanwezig zijn en deels ook nog te misbruiken zijn als de virtual floppy drive controller wordt uitgeschakeld in de hypervisor. Veel virtualisatiesoftware zou inmiddels een update hebben gekregen, waardoor de kwetsbaarheid wordt verholpen.

Reacties (48)

[BorgMan]

"Het wordt gebruikt door [OS'en]"

OK, leuk, maar waarvoor dan precies? Waarom heeft een gebruiker nut voor een virtuele floppy?

[Jaaaaap]

Gevirtualiseerde legacy-software?

[The Zep Man]

Gevirtualiseerde legacy-software?

Inderdaad. Hetzelfde met gevirtualiseerde seriële poorten, IDE controllers en disken, etc.

Net als met fysieke machines kan het dus lonen om een virtuele machine kaal te strippen tot alleen de strikt benodigde hardware om zo het aanvalsoppervlak te verkleinen. Een floppy drive is voor veel situaties niet nodig, en wordt daarom (met de benodigde controller) vaak niet standaard meegeïnstalleerd bij een nieuwe VM, waardoor deze kwetsbaarheid niet van toepassing is op veel VM's.

[Reactie gewijzigd door The Zep Man op 26 juli 2024 08:31]

[segil]

Is dat zo? Want in het artikel staat:

De bug zou al sinds 2004 in de broncode van QEMU aanwezig zijn en deels ook nog te misbruiken zijn als de virtual floppy drive controller wordt uitgeschakeld in de hypervisor.

Daaruit leid ik af dat deze lek kwetsbaar is, of de controller nu wel of niet wordt gebruikt.

[Niemand_Anders]

Maar hoe misbruik je op een VM een floppydisk drive welke niet aanwezig is?
Ik snap dat als VM A een floppy disk heeft en daar de exploit wordt misbruitk dat andere VM op dezelfde host zonder floppy disk alsnog benaderd kunnen worden omdat je dan aan alle VM's alsnog een floppy disk kunt toevoegen. Veel VM oplossingen implementeren dit ook nog als zijnde hot-swappable hardware waardoor de nieuwe hardware direct zichbaar is voor het gast OS..

Maar hoe misbruik je dit lek als gen enkele VM op de host een floopy disk heeft?

[massareal]

Het gaat hier om de virtuele "floppy drive" niet of er überhaupt een fysieke aanwezig is.
Deze module wordt blijkbaar altijd geladen, ongeacht of je deze nu "aan" of "uit" hebt gevinkt in je virtuele OS.

[Niemand_Anders]

Misschien moet je mijn post anders nog een keer lezen: Hoe kun je een (virtueel) Floppy Disk exploit misbruiken als *GEEN* van de virtuele machines op de host een virtuele floppy disk heeft toegewezen?

Deze vraag valt in dezelfde category als: Hoe ga jij mijn website hacken als ik hem niet aan het internet hang? Hoe misbruik je een Adobe Flash exploit als Flash niet is geinstalleerd?

[gekkie]

Omdat bijvb Xen gebruik maakt van de Qemu optie "no-defaults" .. waarbij er geen automagische default virtuele devices geemuleerd zouden moeten worden. Maar helaas is de praktijk bij Qemu weerbarstiger (dit is namelijk niet de eerste keer).

Al zou het in dit geval gaan om de floppy controller ipv de floppy drive zelf. En de controller wordt geacht onderdeel te zijn van het platform en zou derhalve niet onder de no-defaults vallen. (en dus default gewoon aanwezig zijn)

[Reactie gewijzigd door gekkie op 26 juli 2024 08:31]

[velenski]

deze word bijvoorbeeld bij proxmox en virtualizor, alleen geladen als deze ook toegevoegd word aan de VM en eventueel later verwijdert.
Als je geen toevoegd kan deze ook niet geladen worden, hoe dan ook.

Bij andere systemen weet ik niet hoe ze het doen maar bij deze 2 zeker niet.

Ik heb dit bevestigd gekregen van beide ontwikkelaars.
Beiden gebruiken dezelfde methodes om Linux KVM mogelijk te maken.

Dus weinig om zorgen over te maken, want van mijn 5000 KVM's is er geen enkele die floppy ondersteund

[fevenhuis]

Als alle virtuele onderdelen welke niet gebruikt worden toch gebruikt worden in een systeem emulatie, kunnen we nog wel even bezig zijn met onverwachte gaten dichten.

Er is hier duidelijk iets mis met de emulatie.

[freshy98]

Ik gebruik het om nieuwe CRL's van de RootCA te halen die geen netwerk verbinding heeft.
Die VFD kan ik dan weer aan de Sub-CA's hangen.

[The Zep Man]

Ik gebruik het om nieuwe CRL's van de RootCA te halen die geen netwerk verbinding heeft.
Die VFD kan ik dan weer aan de Sub-CA's hangen.

Dan gebruik je toch een seriële poort die maar éénrichtingsverkeer toestaat? Dan kan het iets meer geautomatiseerd.

Maar inderdaad, wat je noemt is een toepassing. Het is universeel en low-tech genoeg om relatief veilig bestanden uit te wisselen tussen VM's via eenrichtingsverkeer.

[Reactie gewijzigd door The Zep Man op 26 juli 2024 08:31]

[freshy98]

Serïeel zou kunnen, als ik zin en tijd heb om uit te zoeken hoe het ook alweer moet.
Te lang geleden :-)
Plus dat dan alsnog de RootCA aan een andere server komt te hangen, wat ik juist absoluut niet wil hebben natuurlijk.

[goarilla]

Om paraat te zijn voor wanneer die oude controlePC's die Windows 3.11 en MS DOS 6.22 nog draaien het begeven. En een onderzoeker je naar de oren schreeuwt omdat zijn doctoraat in het gedrang komt.

[Henk Poley]

Kleine gegevens die je mee geeft aan je grote VM image. Bijvoorbeeld webserver configuratie. Hoeft allemaal niet veel te zijn. Gewoon wat adressen hoe het systeem zichzelf moet noemen, beveiliging-certificaten, en een verwijzing naar een git repo waarvandaan de meest recente versie van je software opgehaald wordt.

Ken ook systemen die daar een CD ISO voor gebruiken. Voor optische schijven is het vaak meer standaard dat het alleen lezen is. Dat had in dit geval vast wat uit gemaakt.

[Reactie gewijzigd door Henk Poley op 26 juli 2024 08:31]

[foxhunt]

Het was natuurlijk wachten op z'n bug, openstack gebruikt kvm ook vaak als onderliggende hypervisor, dus dat wordt dan wel snel updaten.

[MAX3400]

Updaten? Het bijbehorende CVE-2015-3456 is "net" gepubliceerd dus het kan nog even duren voordat er een patch zal uitkomen, zeker voor produkten die zware produktie draaien en misschien niet meteen kunnen worden aangepast.

Het probleem is gelukkiger kleiner dan sommige mensen zullen lezen: je moet kernel-permissies hebben op het guest-OS en je moet de mogelijkheid hebben om bepaalde commando's te loopbacken naar de hypervisor. Door het uitschakelen van de virtuele floppy en het handmatig nalopen van je VM-config, is de attack-surface al een stuk kleiner.

Ook zou je kunnen bekijken/bedenken of per guest-OS het mogelijk is om de drie initiele commando's expliciet te verbieden. Of dit wenselijk is, is een tweede maar over het algemeen zal je deze commando's toch al niet gebruiken op dagelijkse basis tenzij je 24/7 een virtuele floppy moet uitlezen.

[gekkie]

Patches worden bij responsible disclosure gelijk uitgebracht met info over de exploit.
Er zit dan meestal ook een redelijk tijd tussen de eerste melding en de bekendmaking van de exploit inclusief CVE.
Bij Xen hebben grote projecten met securityteams en cloud providers etc al eerder kennis van de exploit en mogen (zolang het de kans op voortijdige kopenbaring van de exploit niet vergroot) ook hun systemen aanpassen / patchen.

Zie hier bijvb de patches voor Xen:
http://xenbits.xen.org/xsa/advisory-133.html

Bij Xen zie je het opzich wel aankomen omdat het XSA nummer op een gegeven moment in het proces wordt gereserveerd en er een release/ einde embargo datum bekend wordt gemaakt.

[Reactie gewijzigd door gekkie op 26 juli 2024 08:31]

[WhatsappHack]

Okee ik hap even.
Waarom was het "natuurlijk wachten op zo'n bug"? Hoezo precies?

Ik bedoel, ik kan zelf wel een solide redenatie bedenken om die claim te maken; maar ben toch benieuwd hoe jij precies dacht, en waarom je het "natuurlijk" vindt?
Zulke uitleg kan mensen helpen.

[jimbo123]

Nee hoor, cloud is echt super veilig. Het is onmogelijk dat de ene klant ooit in een VM van een andere klant komt. Dat is gescheiden.

uh-huh.... nu is het Xen, straks is het VMWare en dan Hyper-V... alles kan gehackt worden.

Stel je voor dat iemand op deze manier buiten een Azure VM breekt en toegang tot het platform krijgt. Dan zijn de rapen gaar...

[magneet]

VMware heeft niet voor niks sinds ESXi 5.5 TPS al standaard uitstaan. Er bestaat een zeer kleine maar reeële kans dat anders in een multi-tenant omgeving de ene klant data van de andere in kan zien.

[jimbo123]

TPS of niet... er is altijd communicatie tussen de host en een vm. Een overflow is dan ook altijd denkbaar. Je kunt nooit uitsluiten dat ergens een lek zit dus Multi-tenant is gewoon gevaarlijk.

[gekkie]

Iemand kan ook je standalone server uit het serverrack vissen ..
netto netto is er uiteindelijk niets totaal ongevaarlijk .. zelfs niet onder (of op) een berg stenen gaan zitten ..

[Reactie gewijzigd door gekkie op 26 juli 2024 08:31]

[subutux]

Dat is nu 's t eerste wat ik uitzet bij 't maken van 'n VM. Ik snap trouwens niet waarom deze standaard nog aangemaakt worden bij bvb 'n nieuw VM IN Vmware Vsphere ?

[CH4OS]

Dan is de controller voor de floppy drive nog wel aanwezig en juist daar zit de bug. Waarom het aanstaat, dat is voor legacy.

[Marctraider]

Gebruikt er nog iemand een virtuele floppy drive dan? Gebruik dan wel VMWare WS maar zet alle onnodige controllers en crap uit.

[CH4OS]

Volgens mij kan je in vmware enkel de drive verwijderen, niet de controller (die op het -virtuele- moederbord zit).

[Verwijderd]

Om de bug in de virtuele-floppycontroller te misbruiken, dient een aanvaller of de gebruikte malware wel over rootrechten of administrator-toegang te beschikken voor het betreffende virtuele gastsysteem.


Tsja, lekker boeiend dan. Is dan toch niet meer interessant ? Ik kan ook op windows/linux inloggen als admin/root en het systeem down gooien.

[Vulpes_Vulpes]

Stel je hebt een virtueel serverpark waarop verschillende partijen (afdelingen of zelf bedrijven) een server afnemen waarop zij volledige rechten hebben. Je kunt dan best je eigen server down gooien maar daar heb je dan alleen jezelf mee. Door deze exploit kun je dus ook gaan rommelen in de andere servers die op hetzelfde metaal draaien. En dat is dus zeer onwenselijk.

edit:

En als je het schema bekijkt bij het artikel suggereren ze dat het dus zelfs via een webserver kan waarop je via een andere exploit root rechten hebt verkregen. Dat scenario is niet geheel ondenkbaar...

[Reactie gewijzigd door Vulpes_Vulpes op 26 juli 2024 08:31]

[Verwijderd]

Dat lees je (volgens mij) niet goed, er staat namelijk dat het om de betreffende server zou gaan.
Er wordt niet gesproken over andere servers.

aanvulling:
Er wordt gesproken over het gast systeem, niet het host systeem

[Reactie gewijzigd door Verwijderd op 26 juli 2024 08:31]

[MAX3400]

Als je toegang hebt tot de host, kan je alles guests herconfigureren, uitzetten, verwijderen, als je daar zin in hebt.

Verder hebben hypervisor-hosts vaak ook pooled resources of communiceren ze met andere hosts; de inrichting van al die hosts is vaak gebeurd met dezelfde credentials en zou je die ook kunnen overnemen.

Of, als je toch als host A kan overnemen, migreer je de guest naar host B en voer je hetzelfde grapje uit en zit je op de kernel, als root/admin, van host B.

[Durandal]

Ja, je komt dus vanuit je betreffende virtuele gastsysteem waar je root/admin rechten hebt via een buffer overflow exploit in de host server, of in een sibling virtueel gast systeem op diezelfde host server. De host server and de sibling VM hoeven niet van jou te zijn en daarin ligt het gevaar.

[gekkie]

Probleem is dat het qemu process op de host draait .. met rootrechten .. en je door de bufferoverflow vanuit je guest dus arbitraire code kunt executen met root-rechten op de host.
En dat is dan weer vrij lullig zeker als je een cloud/vps provider bent.

[Verwijderd]

Ah, op die fiets, ik zou je plussen, maar dat mag niet ;-)

Bedankt voor de uitleg

[MAX3400]

Tsja, lekker boeiend dan. Is dan toch niet meer interessant ? Ik kan ook op windows/linux inloggen als admin/root en het systeem down gooien.

Dat jij kan inloggen als admin op een gevirtualiseerde Windows-machine, heeft als resultaat dat jij 0 permissies/privileges op Linux hebt. Doordat de hypervisor wel volledige permissies heeft op de Linux-kernel en jij via een soort loopback deze permissies weet te hijacken, mag je ineens alles op Linux.

[i-chat]

het hele punt is hier, dat het dus niet 'meer' veilig is om rootrechten te geven op een guestOS, omdat je zodoende ook opdrachten kunt uitvoeren op het hostOS, dan breek je dus uit je virtuele gevangenis en eens je rechten op het host os hebt, kun je ook rechten krijgen op andere guestOS'en...

in de practijk betekend zoiets, huur een vpsje met 128mb ram en breek uit, en installeer vervolgens botnet clients op alle vm's in het cluster...

trouwens een andere note: virtualbox gebruikt deze code ook... dus mensen die een vm gebruiken om potentiele onveilige software te virtualiseren zullen ook op moeten passen.

[Bor]

Ik kan ook op windows/linux inloggen als admin/root en het systeem down gooien.

Daarmee zou je in de praktijk slechts een guest systeem draaien. Door slim gebruik te maken van de hier genoemde vulnerability krijg je toegang tot de hypervisor en daarmee tot alle guest systemen die op diezelfde hypervisor draaien. Daar kun je hele leuke dingen mee doen zoals het beinvloeden van het geheugen van de guest systemen, deze simpelweg afluisteren en ga zo maar door.

[gekkie]

Standaard wordt er in Xen geen virtuele floppy geconfigureerd, of daarmee het codepath ook totaal niet te executen is blijft natuurlijk de vraag. maar het codepath kan kennelijk toch nog geexecute worden.

Maar goed Qemu blijft een hoop code die draait als root en waarbij ontwikkelaars soms wat eigenaardige keuzes maken voor wat betreft de parsing van de configuratie opties (auto config voodoo), waarbij er opeens opties en worden ingeschakeld waar je niet expliciet om hebt gevraagd.
Dat is een nachtmerrie om tegenaan te programmeren voor libraries zoals libxl (xen toolstack). In plaats van "alles is default uit .. en je krijgt waarom te vraagt" .. moet je dus "deels dingen expliciet uitzetten die je niet wil" .. dat is natuurlijk een security disaster waiting to happen als er opties worden toegevoegd of veranderd.

Zit wat dat betreft met smart te wachten op PVH onder Xen .. wel hardwarevirtualisatie container en de isolation en performance voordelen, maar geen complete hardware emulatie van qemu (en grote root running binary) meer. Helaas gaat de ontwikkeling du moment niet zo vlot.

[Reactie gewijzigd door gekkie op 26 juli 2024 08:31]

[johnkeates]

Dit is dus alleen in non-standaard configuratie waarbij je zelf de floppy controller aan zet een probleem.

[borft]

Lezen is moeilijk he, floppy controller uitzetten heft het probleem dus _niet_ op! Nu is het maar even wachten op updates. Tot zover heb ik alleen packages gezien voor Red Hat, maar nog niets voor Debian of Ubuntu.

[johnkeates]

Ja, lezen is heel moeilijk, want:

De bug zou al sinds 2004 in de broncode van QEMU aanwezig zijn en deels ook nog te misbruiken zijn als de virtual floppy drive controller wordt uitgeschakeld in de hypervisor.

Gaat dus vooral over QEMU binaries waarbij de floppy controller ingebakken zit. Ik heb het over binaries waar die niet in zit by default en ook de modules standaard niet mee geïnstalleerd of ingeschakeld worden.

Uitschakelen != configuratie van je VM aanpassen, maar dus de controller in de build configuratie van QEMU standaard niet haan hebben.

[vinnie8690]

Wordt met Xen gerefereerd naar Citrix XenServer of is dat een wezenlijk verschil?

[MAX3400]

http://en.wikipedia.org/wiki/Xen

XenServer is een smaak/vorm van Xen

[sj31]

Lekker is dit, ik ga goed oppassen!

[CH4OS]

Zo te lezen uit het artikel zijn er al patches beschikbaar, wellicht ook voor hetgeen wat jij gebruikt? Daarnaast ga je het niet redden met oppassen alleen, voorkomen is beter dan genezen, ala het echt kritische vm's zijn.