czy luka w zabezpieczeniach widma może znajdować się na maszynie wirtualnej?

Czy to możliwe, że maszyna wirtualna taka jak VirtualBox ma „widmo” podatności? Myślę, że maszyna wirtualna może wykonuje poza kolejnością, ale moim zdaniem nie jest możliwe zerknięcie do pamięci podręcznej w celu odczytania wyniku.

Czy jest jakieś wyjaśnienie, w jaki sposób można odczytać pamięć podręczną wirtualnego procesora?

Tak, małe badania potwierdziłyby, że VMWare wydało łatki do Spectre i Meltdown. System operacyjny gościa musi zostać załatany dodatkowo do faktycznego hiperwizora (oba typy)

— Ramhound

Powiedziałbym, że zależy od poziomu wirtualizacji. Jeśli symulujesz wirtualny procesor, prawdopodobnie jesteś bezpieczny. Ale nie to robią współczesne maszyny wirtualne.

— Bergi,

Czy jest jakieś wyjaśnienie, w jaki sposób można odczytać pamięć podręczną wirtualnego procesora?

Szczegóły @jms znajdują się w kanonicznym poście, który zamieściłem w odpowiedzi:

Spectre works on a different level ... In this attack, the attacker tricks the speculative execution to predictively execute instructions erroneously. In a nutshell, the predictor is coerced to predict a specific branch result that results in asking for an out-of-bound memory access that the victim process would not normally have requested resulting in incorrect speculative execution. Then by the side-channel, retrieves the value of this memory. In this way memory belonging to the victim process is leaked to the malicious process.

— Mokubai

@jms Wirtualizacja jest szybka tylko dlatego, że wykorzystuje fizyczny procesor z jak najmniejszą ilością abstrakcji i polega na sprzęcie procesora w celu zapewnienia izolacji i abstrakcji. Rzeczy takie jak qemuemulacja mogą być bezpieczniejsze, ponieważ nie jest to procesor sprzętowy , ale jest znacznie wolniejszy i różni się od wirtualizacji.

— Mokubai

Tak Spectre może przekraczać granice hosta / gościa, gościa / hosta i gościa / gościa, ponieważ jest to usterka na poziomie procesora, co oznacza, że potencjalnie wrażliwe informacje mogą przeciekać przez wszystko, co działa na rdzeniu procesora.

Większość wiadomości w Internecie mówi o tym, że dostawcy usług w chmurze są tym najbardziej dotknięci, ponieważ mają ogromne klastry systemów, które są zwirtualizowane i mogą potencjalnie zostać wykorzystane do ujawnienia poufnych informacji.

Większość dużych dostawców powinna już być załatana wady, najlepiej jak potrafią, ale będzie to problem, który będzie istniał przez jakiś czas.

Security.SE ma kanoniczne pytania i odpowiedzi na ten temat i wspomina o maszynach wirtualnych:

Używam maszyny wirtualnej / kontenerów, w jakim stopniu jestem podatny na atak?

Zgodnie z odpowiedzią Steffena Ullricha

Ataki topnienia nie przenikają do maszyn wirtualnych, tylko wycieku pamięci jądra do procesów lokalnych.

Spectre może działać na różnych maszynach wirtualnych.

Również od Steffen Meltdown i Spectre współpracują z kontenerami, ponieważ kontenery zależą od jądra hosta.

Maszyny wirtualne używają rzeczywistego procesora w systemie, a niektóre uprzywilejowane instrukcje są uwięzione i można je przekierować. Używa tych samych pamięci podręcznych i instrukcji, co host. Jest to zasadniczo kolejna warstwa fizycznego procesora w systemie.

Wirtualizacja jest szybka tylko dlatego, że wykorzystuje fizyczny procesor z jak najmniejszą abstrakcją i opiera się na sprzęcie procesora w celu zapewnienia izolacji. Rzeczy takie jak qemu mogą wykonywać emulację, co byłoby bezpieczniejsze, ponieważ nie jest to procesor sprzętowy, ale jest znacznie wolniejsze i różni się od wirtualizacji.

Z kanonicznego postu Security.se ponownie:

Spectre działa na innym poziomie i nie pozwala na dostęp do danych w przestrzeni jądra z przestrzeni użytkownika. W tym ataku atakujący oszukuje wykonanie spekulatywne, aby przewidywać błędne wykonywanie instrukcji. W skrócie, predyktor jest zmuszony do przewidywania określonego wyniku gałęzi (jeśli -> prawda), co powoduje prośbę o dostęp do pamięci poza zakresem, którego normalnie nie zażądałby proces ofiary, powodując nieprawidłowe wykonanie spekulacyjne. Następnie przez boczny kanał pobiera wartość tej pamięci. W ten sposób pamięć należąca do procesu ofiary wycieka do złośliwego procesu.

Ponieważ maszyna wirtualna działa na rzeczywistym sprzęcie CPU, wystarczy uruchomić określoną pętlę, aby „wyszkolić” spekulacyjny silnik wykonawczy. Następnie może użyć precyzyjnego pomiaru czasu, aby oglądać pamięci podręczne dla określonych wzorców dostępu wskazujących na proces hosta lub gościa (lub innej maszyny wirtualnej), który chce wykorzystać.

W ten sposób oznacza to, że maszynę można wykorzystać we wszystkich kierunkach. Od hosta do VM, od VM do hosta oraz od VM do VM.

Tak, nie jest to wcale łatwe i trudne do ściągnięcia, ponieważ rdzeń procesora VM może się zmienić na kaprys hosta, a host może z przyjemnością planować zadania na różnych rdzeniach, ale przez długi czas wystarczająca ilość informacji może zostać wyciekły, aby wydać tajny klucz do jakiegoś ważnego systemu lub konta. Biorąc pod uwagę wystarczającą ilość czasu i odpowiednio skryte oprogramowanie, wszystko jest potencjalnie otwarte.

Jeśli chcesz mieć „bezpieczną” maszynę wirtualną, musisz zagwarantować, że jej rdzenie są izolowane. Jedynym prawdziwym sposobem na zablokowanie tego ataku byłoby „wymuszenie” hosta i maszyn wirtualnych do używania tylko niektórych rdzeni, aby nigdy nie działały na tym samym sprzęcie, ale prowadziłoby to do skutecznego wzrostu kosztów, ponieważ nie byłbyś w stanie mieć tyle maszyn wirtualnych na danym hoście. Nigdy nie będziesz w stanie uniknąć większej liczby maszyn wirtualnych niż dostępnych rdzeni, co jest czymś, czego spodziewałbym się na serwerach „niskiego obciążenia”, ponieważ wiele systemów pozostaje bezczynnych przez 90% swojego życia.

— Mokubai
źródło

Myślę, że zinterpretowałeś to pytanie jako „jeśli dotyczy to procesora hosta, czy dotyczy to również maszyny wirtualnej?” Rozumiem pytanie, które brzmi „jeśli nie ma to wpływu na procesor hosta , czy nadal może to dotyczyć maszyny wirtualnej ?” Czy możesz to wyjaśnić?

— AndreKR

@AndreKR: obecnie na wszystkie procesory poza kolejnością ma wpływ Spectre; tylko dzięki rozwiązaniom programowym można uczynić system w pewnym stopniu bezpiecznym (a zatem maszyna wirtualna musiałaby się tym przejmować, chociaż hiperwizor może odizolować gości od siebie, jeśli procesor zapewnia takie udogodnienia, np. sprzęt IBRS firmy Intel). Ale na procesorze w kolejności, bez spekulatywnego wykonania, między dwoma programami nie mogą występować żadne podatności Spectre. Istotą Spectre jest prowokacja spekulatywnego wykonania czegoś, co wprowadza tajne dane w stan mikroarchitektoniczny; kolejność procesorów nie.

— Peter Cordes

Najciekawsze nie jest wykonanie spekulacyjne. Najciekawsze jest to, jak proces może dowiedzieć się, co znajduje się w pamięci podręcznej - nawet na maszynie wirtualnej.

@jms dostępne ataki w kanale bocznym są ułatwione i przydatne dzięki wykonaniu spekulatywnemu. Proces może nie być w stanie bezpośrednio odczytać wierszy pamięci podręcznej, ale wykonanie spekulacyjne może wyciec informacje, wykonując obliczenia, które wprowadzają wartości do pamięci podręcznej, które mogą zostać wykryte lub wywnioskowane przez ataki czasowe. Sekcja 4 białej księgi z widmem ma dobre wyjaśnienie: spectreattack.com/spectre.pdf

— Mokubai

gem5

Jeśli jesteś zainteresowany badaniem / odtwarzaniem luk wyłącznie przy użyciu emulacji, bez użycia procesora hosta, nie sądzę, aby QEMU było wystarczająco szczegółowe, aby je zaobserwować, ponieważ nie symuluje potoku procesora.

gem5 służy jednak do oszacowania wydajności systemu w badaniach i rozwoju i symuluje wystarczającą liczbę procesorów wewnętrznych, aby obserwować Spectre w całkowicie czystym i kontrolowanym środowisku.

Świetne demo x86_64 z wizualizacją zostało opublikowane na stronie : http://www.lowepower.com/jason/visualizing-spectre-with-gem5.html

Minusem gem5 jest to, że jest znacznie wolniejszy niż QEMU, symulacja jest bardziej szczegółowa.

— Ciro Santilli
źródło