Xen, bardzo popularny monitor maszyn wirtualnych (hypervisor), używany w wielu wdrożeniach na całym świecie, okazał się być podatny na najgorszy możliwy błąd dla maszyn wirtualnych, czyli taki, który umożliwia użytkownikowi maszyny wirtualnej przejęcie pełnej kontroli nad maszyną fizyczną, na której ta maszyna wirtualna została uruchomiona. Błędy tego rodzaju zagrażają najbardziej podstawowej zalecie maszyn wirtualnych, czyli ich separacji.
Xen wydał dzisiaj komunikat bezpieczeństwa nr 148, w którym opisuje w jaki sposób użytkownik maszyny wirtualnej może wykorzystać logiczne błędy w zarządzaniu pamięcią by uzyskać kontrolę nad maszyną fizyczną. Choć szczegóły błędu wyjaśnia w swoim wpisie również Joanna Rutkowska, to nie będziemy udawali, ze rozumiemy technikalia. Najważniejsze dla nas w tej informacji są dwa jej aspekty – potencjalne konsekwencje oraz czas, jaki zajęło odnalezienie błędu.
Wygląda na to, że opisywany dzisiaj błąd obecny był w kodzie Xena od… 7 lat. Xen jest często wybieraną platformą obsługującą prywatne serwery wirtualne W praktyce oznacza to, że od wielu lat zagrożone było bezpieczeństwo takich usług jak Amazon EC2, IBM SotfLayer czy Rackspace Cloud. Dysponując dzisiejszą wiedzą można było przejąć kontrolę nad całym serwerem tych usługodawców wykupując u nich jedynie wirtualną maszynę. Błąd jest także poważnym wyzwaniem dla projektu QubesOS, który właśnie o Xena oparł swoje mechanizmy wirtualizacji. Niestety wygląda na to, że nawet platformom o wieloletniej historii trudno do końca zaufać.
Co dodatkowo w tej sprawie jest ciekawe, błąd zgłosił chiński badacz z zespołu Alibaby. Skoro Chińczycy ujawniają takie błędy, to jakie trzymają w zanadrzu?
Komentarze
„skoro Chińczycy ujawniają takie błędy, to jakie trzymają w zanadrzu?”
a każdy Polak to pijak … i złodziej, bo każdy pijak to złodziej ;)
Oni przejmują serwery fizyczne bez pomocy Xena :)
„Xenie”? A może księżniczka Xenia? = ja bym nie odmieniał tej nazwy własnej, brzmi to co najmniej komicznie, a na pewno mało profesjonalnie.
W języku polskim wszystkie nazwy własne, imiona, itp., itd. odmieniamy. Brzmiało by mało profesjonalnie z błędami językowymi w tekście.
Pozwole sobie wyjasnic na czym polega blad:
Xen mapuje pamiec goscia do prawdziwej pamieci RAM – narazie spoko, nic sie nie dzieje, teraz zracji ze Xen musi pilnowac ktory gosc ma zakres/ilosc pamieci ma ustawione flagi, by bardziej to opisac mozna zrobic tak:
VM1 – 0x0000 – 0x3000
VM2 – 0x3000 – 0x6000
itd …
Narazie spoko? :)
Teraz gosc chce zmienic swoje mapowanie pamieci, zeby to zrobic chce aktualizwac swoja pamiec L2 i tutaj pojawia sie problem jak widac z komentarza w kodzie:
/* Update the L2 entry at pl2e to new value nl2e. pl2e is within frame pfn. */
Zeminiamy wartosc 'karty’ z do, uzywacjac 'tej karty’.
Bardziej po ludzku: W adresie X, ustaw adres Y, z wartosciami Z.
Teraz nasza pamiec posiada 'bity’ 'zewnetrznego’ L2, (czyli hosta), i mamy dostep do pamieci L2 serwera Xen, teroretycznie mozna wymapowac caly RAM/L2 i inne (chociaz nie mam pewnosci :P),
Skoro mamy dostep R/W do pamiec nic nie szkodzi jak zamienimy pare bitow prawda? :)
To tak w wielkim telegraficznym skrocie.
PS: Jak gdzies walnelem bubla i zle to opisalem dajcie znac – haker z mnie taki jak z koziej … :)
CVE-2015-5154 tez w październiku. Błąd polegał na mozliwości ucieczki z maszyny wirtualnej.
Sorry, to jednak było wcześniej (w lipcu)
„Niestety wygląda na to, że nawet platformom o wieloletniej historii trudno do końca zaufać.” – nie uwierzyłem jak to przeczytałem. Zdanie ma co najmniej niefortunny wydźwięk i ogólnie jest bez sensu. Żadnemu oprogramowaniu nie można „do końca zaufać”, dotyczy to także oprogramowania/platformy o wieloletniej historii. Urządzeniom z resztą też nie można ufać i ludziom przy okazji także nie. Taki mały banał żeście wstawili pod koniec newsa.