Teoreetiliselt on külalisüsteem VM täielikult isoleeritud ega suuda isegi hostit "näha", rääkimata selle ründamisest; nii et külaline ei saa VM-ist välja murda. Muidugi on praktikas seda aeg-ajalt juhtunud ( veebiarhiivi link). Rünnak nõuab turbeprobleemi (st programmeerimisvea, millel on vastikud tagajärjed) ärakasutamist VM-i juurutamisel või võimalusel riistvara funktsioonidel, millele VM tugineb. VM-ist väljuvate andmete jaoks on vähe väljumisteid; nt Interneti-juurdepääsu jaoks emuleerib VM virtuaalset võrgukaarti, mis tegeleb ainult madalaima taseme pakettidega, mitte täieliku TCP / IP-ga - seega jäävad enamik IP-pinu probleeme VM-i enda piiresse. Nii et VM-ist väljatulekut põhjustavad vead jäävad harva esinema.

On mõningaid rünnakuid, mille vastu VM on väga tõhus, nt. kahvlipommid. Hostisüsteemi seisukohalt on VM üks protsess. Külalises olev kahvlipomm paneb guest OS-i ajastaja põlvili, kuid hostile on see täiesti kahjutu. Samamoodi ka mälu puhul: VM jäljendab füüsilist masinat, millel on teatud hulk RAM-i, ja selle tõhusaks varundamiseks on vaja umbes sama palju "päris" RAM-i. Sõltumata sellest, mida külaline teeb, ei monteeri VM kunagi rohkem RAM-i kui see. (Te soovite siiski piirata VM-i RAM-i mahtu, näiteks, maksimaalselt 1/2 teie füüsilisest RAM-i mahust, sest täiendav "tõeline" RAM on ketta vahemällu salvestamiseks mugav; ka host-OS soovib mõnda neist kasutada.

Kohustustest loobumine: ma lähen suhteliselt kõrgel tasemel arusaamisele. Kui soovite üksikasjalikku juhendit, ei kuulu see reguleerimisalasse. Lisaks on virtuaalmasinate juurutamiseks muid võimalusi (täielikult tarkvaraliselt), millele see ei kehti. Samuti keskendun "väljamurdmisele" ainult virtualiseerimismehhanismide kaudu - st mitte nendele, mis võivad juhtuda arvutite vahel tegelike võrguhaldurite kaudu.

Mulle meeldivad detailid, nii et siin me minge koos. Esiteks on koodiprojektil mõned suurepärased viited komplekteerijatele x86 protsessori erinevatele režiimidele (reaalne, kaitstud ja pikk) ja virtualiseerimise kasutamisele. Seal on Inteli VT ajaveeb (ma pole kindel, kas Intel seda kirjutas) ja lõpuks on Rootkit Arsenali esimene osa pühendatud x86 selgitamisele ja on suurepärane lugemine. koos ülevaadete ja kena skeemidega. Selle kõigest aru saamine nõuab kannatlikkust, seega annan siin väga lühikese sissejuhatuse selle toimimiseks.

Kuidas me DOS-i käivitades raputasime

DOS-i ja varajase 16-bitise reaalrežiimi süsteemid töötavad segmenteeritud mälumudeliga. Segmentide suuruse üle puudub kontroll ja ühelgi neist segmentidest pole kaitselülitit. Kood laaditakse mälu segmenti ja see töötab; see võib kaugele hüpata teistesse segmentidesse, nii et mis tahes kood, ükskõik kus, võib muuta midagi, sealhulgas luua TSR-koodi (lõpetada ja jääda residendiks) koodijupi, mis osutab lihtsalt ühele IVT-kirjetest (katkestusvektoritabel) oma ruumis olevale aadressile, enne originaali täitmist. Põhimõtteliselt pole kaitset. Puudub. Nada.

32-bitise kaitstud režiimi tõus

Kaitstud režiim muutub kiiresti keerukaks. Sellel on kolm osa - segmentimine, lehitsemine ja PAE. Igaüks nõuab andmetabelit, mis räägib protsessorile selle segmendi, lehe kohta või aitab laiendada aadressiruumi (PAE). Nende hulka kuuluvad kuulsad helilipud (need kehtivad segmentide ja lehtede kohta), mis rakendavad protsessi isoleerimist. Lehekülgede otsimine on viis, kuidas laadida andmeid RAM-ist välja ja kettale ning luua uhkeid asju nagu virtuaalne mälu (vaadake sõna virtuaalne! Me jõuame sinna!)

Pikk režiim

Pikk režiim loob segmenteerimisest ja lihtsalt kohustab PAE / Paging struktuure. Jällegi, et OS-i rakendamine oleks täiesti triviaalne, juhivad Paging mälus olevad struktuurid, mis seejärel seadistatakse spetsiaalsete juhiste abil. Voila, protsesside isolatsiooni saab saavutada õigete seadistustega. Jällegi trivialiseerin veidi ...

Andke mulle virtualiseerimine!

Olgu. Virtualisatsioon on sama üldmõiste . Virtuaalmasinad seadistatakse virtuaalmasina juhtimisstruktuuride abil, mis dikteerivad, kuidas nende mälu kaardistatakse tagasi füüsilisse mällu, suht nagu lehitsemine . Oluline on, et teatud tingimustel peab virtuaalmasin hostilt opsüsteemilt midagi küsima, nagu protsesside eraldamine, nagu tarkvara katkestamine . Need viitavad VM-i väljumistele ja pakuvad hostile teavet, näiteks registrite olek väljumisel. Kinda nagu süsteemikõne .

Kas mõni pahavara võib virtuaalmasinast välja murda?

Nii nagu mis puutub VM-i, siis host-OS-il on kogu oma mäluruum ja see võib nakatuda / kahjustuda / hävitada vastavalt oma soovile.

Mis puutub hostimälu otsesesse mõjutamisse, siis virtuaalne masin seda ei näe, sest ta ei näe seda. Host peab kaardistama vajaliku mälu virtuaalmasinaruumi. Samuti peab ta selles mäluruumis rakendama kõike alates BIOS-ist. Teatud ülesannete jaoks teatud hostiseadmetega suhtlemiseks peab hostimasin seadistama need VM-i väljumistingimused ja siht-VM need käivitama. Kui see juhtub, viiakse kontroll hostile üle.

Seetõttu on kaks võimalikku riskipiirkonda:

1. toimingud, mida host võtab vastuseks VM-ile väljumine. Kui selles käitluses on vigu, võib olla võimalik veenda hostit käivitama midagi, mida ta ei peaks.
2. Igasugune host juurdepääs külalismasina mäluruumile. Pidage meeles, et ringis 0 töötav hostimasina kood võib valsi sisse lükata ja partei kokku lüüa, kui see nii meeldib. Nii juhtub, et saate külalise mälu seada külaliselt (üllatuslikult).

See viib teid oma ärakasutamise mehhanismi juurde. VM-i väljumisrutiinis on vaja viga, seejärel peate suutma veenda seda koodi mõne mälu käivitamiseks, ideaaljuhul kood, mille sisestasite lihtsalt külalise vm-i lehele. Kui see on tehtud, öelge Kansasele.

Nagu Tom Leek ütleb, on VM-id kahvlipommide eest kaitsmisel uskumatult tõhusad. Sarnaselt sellele, kuidas operatsioonisüsteem saab piirata, kui palju mälu protsess eraldab, nii et see võib piirata ka seda, kui palju mälu on VM-iga kaardistatud. Otsas ja külaline OS usub, et see on füüsilisest mälust otsas; host ei eralda seda rohkem kui te ei kasuta selleks VM-i väljumist, mis oleks natuke ohtlik ja ma ei usu, et seda tehakse.

Kuidas tõenäoliselt on see?

Mitte eriti. See sõltub täielikult nendest VM-i väljundrakendustest või hostis oleva külalise mälu lugemisest, kus teie lugemiskoodis on kena viga. Samuti nõuab see, et nimetatud viga võimaldaks teil krahhi juhtida nii, et saaksite sundida käivitamist teie hostil olevale mäluaadressile. VM-i väljund peab sellele mälule juurde pääsema.

Mida ma pole käsitlenud?

1. Rünnakud olemasolevatele tarkvara korstnatele, näiteks TCPIP. Haavatavused on siin samad, kui teil oleks nagunii kaks tegelikku füsikalist arvutit.
2. Tarkvaraga on täielikult virtualiseeritud.
3. virtualiseerimine mis tahes muud tüüpi kiipidel. See kehtib Inteli VT-ga ühilduvate seadistuste kohta.

Lõpuks olen varem väitnud, et protsessi eraldamine on liivakasti vorm. Seda ja seda vastust lugedes peaksite nüüd saama aru, miks ma neid nii defineerin. Protsessiisolatsiooni ja virtuaalsete masinate vahel on x86-s märkimisväärseid sarnasusi.

Uuenda

Niisiis olen sellest veelgi rohkem uurinud, eriti siniste pillide uurimine. See, mida ma kirjeldasin, on väga lihtsustatud kõrgel tasemel vaade. Olen leidnud rohkem üksikasju. Siin on nähtamatute asjade labori kogu sellele pühendatud paber. Selgub, et nende kaitsemehhanismide jutt hõlmas kontseptsiooni keelata kasutajarežiimi lehtedele juurdepääsu sooritamine helinast 0, takistades seeläbi virtuaalse masina mällu paigutatud andmete otsest käivitamist. Selgub, et seda rakendatakse Inteli protsessorites ja Linuxi kernelis on praegu plaastreid. Niisiis, olenevalt sellest, kuidas see läheb, võib juhtuda, et seda laadi rünnakud muutuvad palju raskemaks, isegi kui ekspluateerimine on olemas.

Olen teinud VM-is üsna palju pahavara katsetusi - ühest hostist teise sissemurdmiseks kasutasin enamasti backtrack4. Olen peamiselt VMware Workstationi kasutaja.

Suurim probleem tuleneb võimalusest, et teie VM-i võrguühendus viiks tagasi hostisüsteemi. Soovite võrguühenduse täielikult keelata ja / või kasutada võrku, millel puudub juurdepääs teie hostile.

Mälu piiramine on hea tava. Ma hoian seda tavaliselt umbes veerandini, sama mis teie. Protsessori aeg on piiratud kas tuumade arvuga (või kui teie tarkvaras on täpsemad juhtnupud) protsent protsessori ajast, mis on määratud teie konkreetse VM-i jaoks.

Sihtotstarbelised rünnakud, mis suudavad virtuaalsest keskkonnast välja murda, on olemas ja on kaubanduslikult saadaval - näiteks cloudburst @Hendrick mainib -, kuid on suhteliselt haruldased. Väga hea mõte on oma virtualiseerimisparanduste ajakohasena hoidmine.

Lisateavet leiate siit, siit ja siit.

Lisaks kogu siin toodud heale teabele selle kohta, kas viirus võib VM-ist välja pääseda, tooge välja veel üks kaalutletav probleem:

Pahatahtlik kood võib tuvastada, kas see käivitatakse virtuaalmasinas või mitte. Seda nimetatakse sageli nimeks virtuaalmasina tuvastamine või "punased pillid" ja saadaval on palju tehnikaid.

Pealegi kasutavad mõned viirused ja muu pahavara neid meetodeid, et tuvastada, kas neid käitatakse VM-is, ja kui jah, siis sulgege nende kasulik koormus (vältige pahatahtlikke toiminguid). Nad teevad seda selleks, et muuta inimeste elu raskemaks pahavara ümberehitamine või selle tuvastamine.

Järelikult pole VM hea viis teada saada, mida mõni pahavara teeb. Pahavara ei pruugi VM-ist välja murda, kuid samal ajal ei pruugi see VM-is töötades midagi teha. Kui käivitate selle VM-is ja näete, et see ei tee midagi, otsustage, et see on kahjutu, ja otsustage seejärel käivitada see väljaspool VM-i - võite omandada. Ole seal väljas ettevaatlik.

Mida iganes te kunagi mõtlete, võimaldades bioseadistusel teie arvutiga suhelda, peab häkker neid hõlpsasti manipuleerima või murdma. Ma arvan, et tarkvara, mida kasutate veebis, häkkida. lihtne, sest palju parem oleks osta mälupikendus kui lubada veebirakendusel sellega tegeleda. need mõtted on vaid kindel vaatenurk. uskuge seda või kui teil pole tänapäeval häkkerite jaoks veebiõpinguid, on arvukalt, mida te ei kujuta ette, et nad ütlesid seda üle miljonite kogu maailmas.