Zamknij wroga w symulacji. Prywatność maszyn wirtualnych

Zdjęcie: Kadr przedzielony murem, pod którym widnieje logo VirtualBoxa. Po jednej stronie siedzą ludzie patrzący na cienie na ścianie, po przeciwnej animatorzy z sylwetkami na patykach

W internecie coraz częściej można znaleźć na różnorodnych forach i grupkach pytania o to, jak chronić swoją cyfrową prywatność. Wśród odpowiedzi czasem przewija się krótkie: „używaj maszyny wirtualnej”.

Rada jak najbardziej ma sens. Problem w tym, iż jest ciut enigmatyczna, a dla ludzi spoza świata komputerowego – może choćby kompletnie niezrozumiała.
Dlatego trochę ją odczaruję i pokażę krótko, o co z tymi maszynami chodzi. Opiszę ogólniki, kładąc fundament pod ewentualne przyszłe wpisy na temat VirtualBoxa, systemu Qubes itd.

Zobaczymy, iż czasem od celowego ukrywania skuteczniejsze jest odsłonięcie przed podglądaczami swojej rzeczywistości. Wiarygodnej, zaspokajającej ich ciekawość. Tyle iż nieprawdziwej.

Źródło: ilustracja jaskini Platona z Wikimedia Commons, ikona programu VirtualBox. Przeróbki moje.

Spis treści

• Czym są maszyny wirtualne
• Wycinek szerokiego świata
• Prywatność dzięki izolacji
  • Ochrona przed czytaniem naszych plików
  • Ochrona przed czytaniem plików systemowych
  • Ochrona przed profilowaniem przez czcionki
• Przechytrzenie głęboko zagnieżdżonych programów
• Ograniczenia maszyn wirtualnych
  • Możliwość wykrycia
  • Łączenie informacji z różnych programów
  • Złośliwy hardware
• Przykład z życia: Proctorio
• Podsumowanie

Jeśli komuś nie chce się czytać całości

Czym są maszyny wirtualne

Maszyna wirtualna to po angielsku virtual machine, w uproszczeniu VM. Dla wygody będę czasem skracał do „VM‑ka”.

Skąd nazwa? W informatyce „maszyna” oznacza ogólnie coś, co przyjmuje i wykonuje instrukcje w określonym formacie. „Wirtualna” – czyli jak taka nakładka na coś realnego. Nadbudówka.

Opis brzmi mgliście i ogólnikowo? Trochę tak. Ale ogólność jest uzasadniona, bo samo pojęcie maszyn wirtualnych może obejmować bardzo wiele rzeczy (niektóre krótko omawiam niżej, w rozwijanych ciekawostkach).
W tym wpisie będzie o tyle łatwo, iż odnoszę się tylko do jednej ich postaci – systemu operacyjnego uruchomionego wewnątrz innego systemu.

Jak wygląda takie coś w praktyce, z punktu widzenia użytkowników?
Wyobraźmy sobie, iż mamy zwykłe otwarte okna z różnymi programami. Jak Firefox, Notatnik czy LibreOffice. Można je przesuwać po ekranie, minimalizować itd. Jedno z tych okien odpowiada programowi od wirtualizacji, nazywanemu po angielsku hypervisor.

Przykładem takiego programu jest VirtualBox. Gdy jest uruchomiony, to w jego oknie widzimy – jak na monitorze – wnętrze załadowanego, pełnoprawnego systemu operacyjnego: pulpit, ustawienia, okna itd.

Jeden z wielu wariantów systemu Linux w programie VirtualBox na Windowsie. Źródło: ten film.
Gdyby ktoś chciał spróbować wirtualki z przyjaznym systemem Linux Mint, to przystępny wideoporadnik po polsku można znaleźć choćby tutaj (oba linki: YouTube).

Napisałem wyżej o systemie otwartym wewnątrz systemu, bo to intuicyjnie pasuje do zagnieżdżonych w sobie okienek. Ale żeby łatwiej wyobrazić sobie zalety i ograniczenia dowolnej VM‑ki, zachęcam do myślenia o niej również jak o systemie opartym na innym systemie.

Przedstawiam przeróbkę typowej piramidki, której często używam w różnych wpisach. W przypadku VM-ek jedyna różnica polega na tym, iż na warstwie programów stawiamy kolejny system oraz jego własne rzeczy. Piramida rośnie w górę.

Źródła: procesor z serwisu Flaticon, ikony systemów Windows i Linux Mint oraz programów Firefox i VirtualBox. Przeróbki moje.

Na samym dole mamy fizyczny sprzęt (hardware) oraz sterujące nim programy (firmware). Wyżej główny system (ang. host system; dosłownie system-gospodarz). Na tym systemie otwarte programy, z których jeden to VirtualBox. Na nim oparty inny system (ang. guest system, czyli system-gość). A na tym systemie – jego własne programy.

Wycinek szerokiego świata

Wyżej wspomniałem, iż maszyny wirtualne to rozległy temat. Na potrzeby tego wpisu dość mocno przytnę zakres tematyczny i napiszę jedynie o:

• maszynach rozumianych jako system w systemie;
• działających na komputerze osobistym, a nie telefonie;
• uruchamianych przez program taki jak VirtualBox;
• prywatnościowych zastosowaniach (z lekkim zahaczeniem o ogólniejszy wątek izolacji);
• przeciwnikach działających legalnie (nie uwzględniam hakerstwa).

Nawiązania do innych możliwości dodam jedynie w formie rozwijanych streszczeń. Chętne osoby mogą sobie zerknąć i przekonać się, iż omawiane w tym wpisie sprawy to zaledwie kawałek sporego tortu.

Maszyny wirtualne na telefonach?

Smartfonowy system Android ma u swoich podstaw Linuksa. Coraz śmielej sięga po jego moce, również te związane z wirtualizacją. W nadchodzącej wersji numer 16 ma już być wbudowana możliwość uruchamiania Linuksa w VM‑ce na Androidzie.
Niezależnie od tego powstają projekty eksperymentalne, obchodzące ograniczenia. Już parę lat temu ktoś uruchomił Windowsa na Androidzie, a na Windowsie grę.

…Tylko że, choć te nowinki budzą ciekawość i mają pewien sens z punktu widzenia kompatybilności (uruchamiania czegoś, co na Androidzie by nie ruszyło), nie dają rewolucji w sferze prywatności.

To dlatego, iż prywatnościową cechę maszyn wirtualnych, czyli izolację, mamy na telefonach niejako w pakiecie. W przeciwieństwie do komputerów osobistych, apki telefonowe mają względną odrębność. Każda jest jak osobna całość, z własnymi plikami. Apki bez szczególnych uprawnień nie mogą zaglądać do nieswoich przestrzeni.

W tej izolacji istnieją pewne luki – wspólne pliki i foldery, identyfikator reklamowy czy ogólne ustawienia systemowe. Nie zmienia to jednak faktu, iż domyślnie telefony dają lepszą izolację niż komputery osobiste.

A jeżeli ktoś chce przenieść ją na jeszcze wyższy poziom, to może rozważyć założenie na Androidzie osobnego profilu użytkownika. Pod względem prywatności byłby on telefonowym odpowiednikiem VM‑ki, z innymi aplikacjami i plikami niż nasz główny profil.

Zachęcam jednak, żeby poczytać o metodach profilowania z dalszej części tego wpisu. telefony, dając szeroki dostęp do czujników, mogą być szczególnie narażone na opisane tam metody.

„Programistyczne” maszyny wirtualne

Jeśli ktoś pamięta młodość z komputerami osobistymi, to być może gdzieś w głowie kołacze się nazwa Java Virtual Machine. Takie coś, co trzeba było zainstalować, żeby działały niektóre programy. Nazwa pochodzi od języka programowania Java.

Oprócz Javy z maszyny wirtualnej korzysta parę innych języków, jak Python. Żeby jeszcze bardziej namotać, ten drugi ma w pakiecie rozwiązanie zwane środowiskami wirtualnymi. To jeszcze inna rzecz, dotycząca z kolei instalowania plików.

Tego rodzaju „VM‑ki” są czymś całkiem innym od tych, na których skupia się wpis. Z systemami w systemach czy z izolacją mają kilka wspólnego. A z prywatnością już zupełnie nic.

Skąd zbieżność nazw? Intuicyjnie można sobie wyobrazić, iż wspomniane języki nie rozmawiają bezpośrednio z (realnym) procesorem. Nim się do niego zwrócą, wykonują własne, wewnętrzne instrukcje. Wykonawca instrukcji to w żargonie komputerowym maszyna, a nakładka na coś realnego to coś wirtualnego. Stąd „programistyczne VM‑ki”.

Prywatność dzięki izolacji

Wyobraźmy sobie, iż musimy zainstalować jakiś program, któremu nie do końca ufamy. Nie na zasadzie „jest wirusem”, ale na zasadzie „zbiera moje dane”. Potrzebujemy jego możliwości, ale nie chcemy go stawiać nigdzie obok wrażliwych informacji. A komputer mamy jeden.

W takim przypadku zyskuje na atrakcyjności kluczowa cecha maszyn wirtualnych – izolacja. Odrębność, odgrodzenie od głównego systemu.
Można sobie wyobrazić, iż w każdej VM‑ce siedzi całkiem osobny system. Ma własne pliki, własne ustawienia, własne programy… A to daje ogromne możliwości.

Ochrona przed czytaniem naszych plików

W przypadku systemów na komputerach osobistych (Windows, MacOS, popularniejsze Linuksy) granice między programami są zwykle umowne i nieszczelne.

Po pierwsze: często zapisujemy pliki do publicznie dostępnych miejsc (jak folder Dokumenty). Z założenia chcemy je tam trzymać i co najwyżej wyświetlić czasem w domyślnym podglądzie.
Ale, niezależnie od naszych intencji, mogą tam sięgnąć również inne programy. W przypadku zdjęć mogą na przykład odczytywać współrzędne geograficzne z metadanych.

Po drugie: czasem programy zapisują różne rzeczy do własnych folderów, o nazwach wyraźnie sugerujących, iż to ich foldery wewnętrzne. Przykład: .mozilla/firefox. Ale cóż po nazwie, gdy nie ma żadnych barier osłaniających te miejsca przed innymi rzeczami zainstalowanymi na komputerze?

Pokazałem to już kiedyś na przykładzie pamięci podręcznej przeglądarek. Wystarczył względnie prosty skrypt, żeby sięgać do plików Opery, Chrome’a czy Firefoksa (zapisywanych na dysku, żeby uniknąć wielokrotnego pobierania różnych elementów).

Były tam wszelkiej maści awatary z social mediów czy wyświetlone obrazki, wraz z linkami. Rzeczy, które pozwoliłyby postronnym ustalić, jakie dokładnie treści oglądaliśmy. choćby jeżeli w historii przeglądania była tylko najogólniejsza możliwa nazwa, jak facebook.com.

Inny przykład? Poniżej fragment pliku z historią otwieranych dokumentów, jaki tworzy sobie pakiet OnlyOffice (skądinąd fajny zamiennik Microsoft Office’a). Pełna ścieżka do pliku na moim Linuksie: ~/.local/share/onlyoffice/desktopeditors/recents.xml. Już początek nazwy sugeruje, iż folder jest ogólnodostępny.

Po datach można poznać czyjś rytm dnia. Liczba pozycji na liście ukazuje stopień obłożenia pracą. Nazwy plików – branżę i charakter tejże pracy. I wszystko to odczytane z samych metadanych, choćby bez zaglądania do dokumentu.

To tylko wycinek niezliczonych możliwości, jakie mają aplikacje zaglądające do plików. Na szczęście maszyna wirtualna przed tym chroni – zwyczajnie nie ma w niej naszych plików i folderów. System uruchomiony w VM‑ce wygląda dla wścibskiego programu jak taki po świeżej instalacji.

Ochrona przed czytaniem plików systemowych

Nie tylko pliki od pomniejszych, zainstalowanych programów mogą zawierać wrażliwe informacje. Czasem również ustawienia samego systemu są żywą opowieścią.

Komputer zapisuje na przykład historię hotspotów, z jakich korzystaliśmy, żeby potem automatycznie łapać z nimi łączność. W tej historii są ich czytelne, publiczne nazwy.

Potencjalne programy stalkujące mogą odczytać z takiej historii nasze zamiłowania (Klub_Fitness_Guest, NeuroKonferencja Free) i historię wędrówek (ChataMagory – z życia). A na dłuższą metę również lokalizację (punkty, które najczęściej lądują na liście najnowszych. choćby jeżeli nazwa mało mówi, to da się czasem wyszukać ją w bazie przypisującej hotspoty do współrzędnych geograficznych).

To tylko jeden przykład; oprócz tego są też logi systemowe, systemowa historia wyszukań, z nieco nowszych rzeczy Recall… I mnóstwo innych możliwości, z których wielu dotąd nie poznałem. Pozostawiam wyobraźni.

Ale, niezależnie od natury informacji ukrytych w ustawieniach, czysta VM‑ka przed tym ochroni. Będzie jak nowy komputer z nowymi ustawieniami. Oczywiście warto pamiętać, żeby nie importować swoich ustawień z głównego komputera, zwłaszcza jeżeli są mocno spersonalizowane. Nowa wirtualka, nowi my.

Ochrona przed profilowaniem przez czcionki

Profilowanie przez czcionki jest o tyle ciekawe, iż może je wykonywać choćby (mocno ograniczany przez przeglądarkę) kod ze stron internetowych, które odwiedzamy.

Działa to tak, iż kod na stronach prosi przeglądarkę o uformowanie tekstu napisanego konkretną czcionką. Przeglądarka, reagując na prośbę, sięga do wspólnego systemowego folderu. jeżeli nie znajdzie tam szukanej czcionki, to używa zastępczej.

Prosząc o wiele różnych czcionek i analizując efekty końcowe (użyto żądanej czy zastępczej), strony internetowe mogą ustalać, jaki zestaw czcionek u siebie mamy. I odróżniać nas na tej podstawie od innych osób.

Świeża VM‑ka ochroni przed wieloma formami profilowania przez czcionki. Z tego prostego względu, iż zawiera tylko czcionki domyślne systemu-gościa, który w niej zainstalowaliśmy.

Oczywiście na dłuższą metę, w miarę instalowania przez system z wirtualki różnych czcionek znalezionych w sieci, również zacznie się on wyróżniać.

Przechytrzenie głęboko zagnieżdżonych programów

Teraz coś związanego pośrednio ze śledzeniem, bezpośrednio – z kontrolą.

Zazwyczaj instalacja programu polega na tym, iż grzecznie umieszcza on swoje pliki w określonych folderach. Czasem ustawia wartości jakichś zmiennych systemowych. Potem już podporządkowuje się systemowi pod sobą (przypomnę: hierarchia z piramidy).

Istnieją jednak programy, które domagają się umieszczenia przynajmniej jakiejś swojej cząstki w warstwie głębszej – prosto w jądrze systemu. Dzięki temu pod pewnym względem to one stają się nadrzędne wobec użytkownika.

Przykładem takiego programu był Falcon Sensor, którego błąd doprowadził w zeszłym roku do masowego zawieszenia się komputerów z Windowsem.

Innym przykładem są anti-cheaty, czyli zabezpieczenia przed oszukiwaniem w grach komputerowych. Mając oko na wszystkie procesy działające na komputerze, mogą wyłapać, czy ktoś stosuje na przykład automatyczne celowanie lub wbudowane skrypty.

Mając wielkie przywileje, takie programy zyskują duże możliwości gromadzenia danych. I, co gorsza, trudno im odmówić. jeżeli mniejszy, inwazyjny moduł nie zasygnalizuje głównemu programowi „OK, siedzę w jądrze”, to całość po prostu nie zadziała.

…Ale co, jeżeli damy mu taki uprzywilejowany dostęp, ale tylko do jądra systemu w VM‑ce?
Wilk syty i owca cała. Program sądzi, iż tkwi tam, gdzie powinien. Ale wciąż to my jesteśmy bliżej fundamentu piramidy, bardziej uprzywilejowani.
Nawet jeżeli uznamy VM‑kę za kompletnie przejętą przez zbira, to wciąż pozostaje zaledwie pojedynczym, małym oknem na naszym pulpicie. Oddalonym od tajemnic.

Ograniczenia maszyn wirtualnych

Istnieją rzeczy, przed którymi choćby najszczelniejsza VM‑ka nas nie uchroni.

Po pierwsze: przed błędami ludzkimi. Gdybyśmy na przykład skopiowali na pendrive’a wrażliwe pliki, a potem udostępnili go VM‑ce, to każdy tkwiący w niej cyfrowy gremlin może się dorwać do sekretów.

Ale załóżmy nawet, iż jesteśmy ostrożni. Nigdy nie naruszamy bariery między systemem a wirtualką, do tego co jakiś czas tworzymy nową. przez cały czas pozostaje parę ograniczeń.

Możliwość wykrycia

Podglądacze, skutecznie blokowani przez VM‑kę, mają interes w tym, żeby rozpoznawać takie więzienia wokół siebie. Widząc je, mogą po prostu odmówić działania lub udawać niewinne programy.

A rozpoznanie „życia w symulacji” wbrew pozorom może być całkiem łatwe. Niektóre programy od wirtualizacji bywają gadatliwe. Przykład? Program VMWare umieszczał w plikach konfiguracyjnych, które każdy program może sobie podejrzeć (dokładniej: w polu CPUID) informację o wirtualności systemu.

Takie zachowanie może dziwić, patrząc na opisane wcześniej korzyści prywatnościowe. Ale można uznać, iż są one niejako niezamierzone i wynikają z izolacji typowej dla VM-ek. Ich twórcy niekoniecznie mają prywatność na uwadze.

Gdyby choćby program wprost nie ujawniał podstawowych informacji, pewne rzeczy wciąż pozostaną nie do uniknięcia:

• maszyna wirtualna dodaje kolejny poziom do wszystkich obliczeń, przez co jest wolniejsza niż system pierwotny,
• dostaje jedynie część zasobów (pamięci, miejsca na dysku) od głównego komputera.

Wścibskie programy mogą przeprowadzić serię testów. Trochę w stylu benchmarków do testowania wydajności w grach komputerowych, tyle iż wykonanych w złej wierze. Wyniki testów mogą porównywać ze znanymi wzorcami.

Jeśli ujawnią, iż dany procesor zachowuje się nietypowo jak na swój model (inne wzorce przy stopniowym zwiększaniu obciążenia), to program domyśli się, iż ktoś właśnie go zamknął w VM‑ce. I odmówi działania.

Takich luk jest sporo i mogą być bardzo trudne do załatania. Pomóc może natomiast fakt, iż dyskretniejsze wirtualki rozwijają też badacze cyberbezpieczeństwa, żeby analizować w nich wirusy. Zwykli prywatnościowcy mogą skorzystać z ich dorobku :sunglasses: Przykład? Projekt Pafish.

W odpowiedzi na rozwój metod wykrywania powstały lepsze metody maskujące. Jak CloakBox, ukrywający fakt, iż korzystamy z VirtualBoxa.

Uwaga: nie korzystałem z CloakBoxa, więc nie ręczę za niego i przywołuję go wyłącznie jako studium przypadku. Osoby chętne mogą zajrzeć mu w kod źródłowy i spojrzeć na użyte techniki.

Łączenie informacji z różnych programów

VM‑ki bardzo pomagają, gdy mamy prostą sytuację: wszystko co złe w VM‑ce, rzeczy dobre na głównym systemie, i tak do końca życia (naszego urządzenia).

Jeśli jednak:

1. mamy więcej niż jedną kopię złego programu;

   Czy to w różnych VM‑kach, czy choćby jakąś na prawdziwym systemie. Można dołożyć choćby przypadek, gdy programy są różne, ale zawierają elementy gościnne (SDK) od tej samej firmy od reklam śledzących.

2. każda z kopii programu łączy się przez internet ze swoimi twórcami…

…to zachodzi ryzyko, iż programy zastosują profilowanie (ang. fingerprinting) i zorientują się, iż są w rękach tej samej osoby. Co może być szczególnie groźne, gdyby choć jeden z nich ustalił ponadto dane osobowe.

Takie profilowanie jest możliwe dzięki temu, iż dwie niezależne „nogi”, trzymane w rozkroku dzięki VM‑kowej izolacji, stykają się w fizycznej warstwie systemu.

Źródła: jak wcześniej, plus ikony z serwisu Flaticon.

Niżej niepełna lista informacji, z których programy zamknięte w wirtualnych klatkach mogą zbudować nasz profil.

• Język i strefa czasowa

  Wiele osób, mimo iż oddziela od siebie system realny i wirtualny, może dla wygody ustawić w nich prawdziwy język i strefę czasową. Dla szpicli to dobry sygnał uzupełniający, choć raczej nie główny sygnał demaskujący – chyba iż jesteśmy jedynym polskojęzycznym użytkownikiem z najmniej zaludnionej strefy czasowej.

• Kamerka i mikrofon

  W skrajnym przypadku każdy z programów mógłby uruchomić kamerkę, zrobić zdjęcie naszej gęby i wysłać je do swoich twórców. Algorytmy łatwo rozpoznają, iż zarówno program A, jak i B (z VM‑ki) widziały tę samą osobę. I tożsamości powiązane, dzień popsuty.

  Ale to skrajność. W praktyce programy z VM‑ki, mając dostęp do kamerki, mogłyby zamiast tego sięgnąć do informacji o jej technicznych parametrach (stabilizacji, balansie bieli itd.). Analogicznie z mikrofonem.
  Ponownie: sygnał raczej niegroźny solo, groźny po połączeniu z innymi.

• Hotspoty i internet

  Różne tożsamości w różnych VM‑kach… Ale co z tego, jeżeli łączą się z tym samym internetem?

  Najprostszą cechą łączącą tożsamości może być adres IP. Internetowy odpowiednik adresu pocztowego, nadawany w uproszczeniu przez hotspota, z którym się łączymy.
  Choć jest nieco bardziej zmienny niż adres nieruchomości, wciąż pozwala dojrzeć powiązanie: „różne programy, A i B, uruchamiane krótko po sobie, piszą do nas z tego samego IP! Być może mają tego samego użytkownika”.

  To może spróbujemy ukryć adres z VM‑ki za jakimś pośrednikiem (np. VPN-em), którego nie używamy poza nią? Istotnie, wtedy adresy byłyby inne. Ale ku przestrodze: choćby w skądinąd szczelnych przeglądarkach, jeżeli nie zadbamy w ustawieniach o parę szczegółów, wścibscy podglądacze mogą czasem wymusić tryb wideokonferencji, żeby dorwać prawdziwy adres IP zza pośrednika.

  Załóżmy, iż to naprawiliśmy. Ale jeżeli program w VM‑ce i program spoza niej mają możliwość sprawdzania aktualnych hotspotów wokół nas – czyli zarówno czytelnych nazw, jak McD Hotspot, jak i identyfikatorów BSSID – to łatwo powiążą tożsamości.

  Wyżej pisałem, iż VM‑ka pomaga przy ukrywaniu systemowej historii połączeń z hotspotami. Tutaj mówię o danych napływających na bieżąco, jeżeli mamy łączność z siecią.

• Procesor, karta graficzna, karta dźwiękowa…

  Po pierwsze – programy mogą po prostu zapytać. Pewne ogólne informacje, jak te o procesorze (na Linuksie z pliku /proc/cpuinfo), są ujawniane na życzenie.

  Wspomniałem wcześniej, iż programy mogą zmuszać komputer do wykonywania benchmarków, żeby ustalić, iż zostały zamknięte w VM‑ce. Podobnymi testami mogą ustalić charakterystyczne cechy wyróżniające nasz sprzęt.

  Można powiedzieć, iż elementy fizyczne mają swoje tiki. Jeden procesor szybciej rysuje kształty niż inny, a po osiągnięciu liczby X trójkątów następuje w nim skokowe spowolnienie. Karta dźwiękowa trochę „ścina na brzegach” i „spłyca scenę przy mocnych basach” (pozdrawiam twórczość audiofilską :wink: ).

  Do takich informacji sięgają choćby strony internetowe, poprzez kod JavaScript. Mimo iż przeglądarki narzucają na nie restrykcje i nie ujawniają zbyt wiele. Zainstalowane programy widzą jeszcze więcej, będąc bliżej systemu i sprzętu.

Złośliwy hardware

Pokazałem wcześniej, iż można „przelicytować” złośliwe programy chcące wniknąć do dolnej warstwy. Dać im miejsce w jądrze systemu, ale jedynie w tym wirtualnym, trzymając realne z dala od nich.

Ale w podobny sposób inni mogą przelicytować nas. Jeśli mają swojego „agenta” w warstwie fizycznej, to koniec gry, będzie on poza naszym zasięgiem. I może na przykład meldować złemu programowi, iż chcemy go oszukać przez wirtualizację.

Tacy fizyczni agenci nie są niestety moim wymysłem ani straszeniem. We współczesnych urządzeniach układy z założenia odizolowane od użytkowników są na porządku dziennym.

Jednym z tego rodzaju układów jest Intel Management Engine, czyli swego rodzaju „system u podstawy systemu”. Procesory Intela nie zadziałają, jeżeli się nie uruchomi. A gdy już się uruchomi, to ma pełną władzę nad głównym systemem, dostęp do jego pamięci i każdej wykonywanej instrukcji.
Na procesorach AMD jego odpowiednikiem jest Platform Security Processor.

Innym rodzajem tych elementów są mniejsze układy kryptograficzne, takie jak Trusted Platform Module. Wymagany przez nowego Windowsa.

Układy mogą dawać osobom z zewnątrz, jak twórcy wścibskich programów, bardzo silne gwarancje. Szczególnie wredna jest zdalna atestacja (omówiona krok po kroku w tym wpisie; próba jej praktycznego uzycia przez Google’a jest z kolei tutaj).

Atestacja polega na tym, iż ktoś może wysłać do fizycznego chipa pytanie o to, czy jest w tej chwili na realnym, niemodyfikowanym systemie. Odpowiedź z założenia zawsze będzie prawdziwa i niemożliwa do podrobienia – jest oznaczona cyfrowym podpisem, który może stworzyć wyłącznie element zamknięty w mikroukładzie.

Ogólnie można przyjąć taką regułkę: jeżeli coś jest związane z fizycznym sprzętem, to żadne VM‑ki nas nie ocalą. Dokładanie górnych warstw nie pomoże przeciw wrogom siedzącym w fundamencie. choćby gdyby sami nie zbierali danych, mogą przynajmniej donosić zbieraczom, iż jest frajer do golenia.

Przykład z życia: Proctorio

Na koniec, po tych wszystkich rozważaniach, coś życiowego.

Kilka lat temu, za czasów pandemii, chwilowy boom przeżyły wszelkie formy pracy i nauki zdalnej. Jak nauka, to egzaminy. A na nich zdarza się ściąganie. Uczelniom nie było w smak, iż nie mają jak mu zaradzić.
Wówczas, wśród innych podobnych produktów, na scenę całe na biało weszło Proctorio. Dość inwazyjny program komputerowy analizujący, czy ktoś nie ściąga podczas egzaminu. Oceniali to m.in. na podstawie obrazu z kamerki internetowej i metod uczenia maszynowego (potocznie: AI).

Choć nazwa kojarzy się z jelitami, jej trzonem jest w istocie proctor. W anglosferze nadzorowanie ludzi podczas egzaminów dotąd nazywa się proctoringiem.

Twórcy programu oczywiście przedstawiali swoje algorytmy jako niezawodne. Coś, w co każda szanująca się uczelnia powinna zainwestować. W praktyce dość gwałtownie odkryto, iż prawdopodobnie korzystali z darmowego pakietu OpenCV, nie wnosząc zbyt wiele innowacji.

Co gorsza, algorytmy potrafiły nękać negatywnymi opiniami osoby w jakikolwiek sposób nietypowe. Wyróżniające się kolorem skóry, zezem, rozbieganym wzrokiem, zwykłymi tikami polegającymi na błądzeniu wzrokiem… Proctorio potrafi(-ło) przerwać ich egzamin i oflagować ich zachowanie jako podejrzane, do oceny przez egzaminatorów.

Jeden z głośnych krytyków działań firmy, Ian Linkletter z kanadyjskiej uczelni, został przez nich pozwany po tym, jak udostępnił parę linków do ich filmików. Były rzekomo niejawne, więc firma oskarżyła go o naruszenie praw autorskich.

Walka Linklettera z Proctorio toczy się już kilka lat. Sąd w Kanadzie, wbrew rozumowi i godności człowieka, nie uznał pozwu Proctorio za SLAPP, czyli zastraszanie drogą prawną. Rozprawa będzie zatem musiała się odbyć, walka trwa. Oburzeni mogą wesprzeć pana Linklettera.

Ogólnie: Proctorio i automaty oceniające nie budzą sympatii i wiele osób chętnie by im zagrało na nosie. Jednym ze sposobów byłoby właśnie uruchomienie programu pilnującego w VM‑ce. Żeby nasycić jego chęć dostępu do głębszych warstw systemu.

Tenże (wirtualny) system można otworzyć w oknie na jednej połowie ekranu. A na drugiej połowie, w oknie należącym już do pierwotnego systemu – notatki, z których coś można sobie czytać. Żadna aplikacja nie powinna być w stanie wychylić się z VM‑ki i dojrzeć, co ktoś porabia na prawdziwym systemie.

Nie pójdzie to raczej jak po maśle, bo Proctorio dobrze zna taką metodę obejścia. Na swojej stronie piszą, iż ich program nie będzie działał w maszynach wirtualnych. Do tego aktywnie wykrywają ich istnienie i odmawiają działania.

Maszyny wirtualne: jeżeli w chwili łączenia się z nami twój program działa w maszynie wirtualnej, poprosimy cię o wyjście z niej i uruchomienie programu na twoim głównym systemie w celu podejścia do testu.

Tłumaczenie moje.

Bardziej zmotywowane osoby mogłyby przeanalizować, na jakiej podstawie Proctorio wykrywa VM‑kę wokół siebie, i jakoś ją zamaskować. Swoją działającą konfiguracją mogą się potem dzielić z innymi. Taki wesoły, buntowniczy wyścig zbrojeń.

Część Twitterka (tu wyświetlona przez xcancel.com) nie wierzy w studencki potencjał. Ja wierzę :smile:

Podsumowanie

Maszyna wirtualna jest przydatnym narzędziem w prywatnościowym arsenale. Czymś w rodzaju drugiej tożsamości lub maski, którą na pewien czas zakładamy.

Ukrywa to, co nagromadziliśmy na głównym dysku, zapisane opcje i preferencje. Zamiast nich pokazuje proste, świeże, dość bezpłciowe oblicze. Jest idealna w przypadku, gdy chcemy u siebie zainstalować jakiś program, któremu nie do końca ufamy.

Zaczyna jednak nieco zawodzić w przypadku, gdy chcemy trzymać dwie tożsamości na jednym urządzeniu, a każda z nich wchodzi w interakcje z potencjalnym programem-podglądaczem.
Istnieją metody pozwalające ustalić, iż osoba A to tak naprawdę osoba B, kiedy obie VM‑ki są na tym samym kompie/laptopie. jeżeli bardzo nam zależy na rozdzieleniu tożsamości, to silniejsze gwarancje daje korzystanie z całkiem osobnego urządzenia i sieci.

Jeśli przeciwnik aktywnie próbuje wykryć VM‑kę – choćby przez proste testowanie wydajności – to rozpoczyna się wyścig zbrojeń. Być może jakoś przechytrzymy podglądacza, być może on nas. Ale na tym etapie VM‑ka przestaje być komfortowym rozwiązaniem dla codziennego użytkownika.

Życzę, żebyśmy jednak nie nadziali się na tak zdeterminowanych dziadów, a wirtualna maska skutecznie zasłaniała nasze prawdziwe oblicza. Pozwalając je zostawić dla tych osób, które na nie zasługują :smile: